Issue 13135: SBVR Issue: can a role range over multiple object types (sbvr-rtf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". Resolution: Revised Text: Actions taken: December 3, 2008: received issue Discussion: End of Annotations:===== ubject: SBVR Issue: can a role range over multiple object types DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:In-reply-to:X-MimeOLE:Thread-Index; b=IEIRZMnJtmhACgK+OyyDCbj1muvkJp/M+SjGcuzXtUmGfmsNCsybA5FT6r3mgaYequlW9IkYtzYLY7IBb4LUrQOVGMA9yiKrpr6UlU7AiLtlme6EKdWd8L7HQLdfId6ydXsKE2ILdLO1gTkCV91WAhFmcFCz/oYUTFgHtVvhz9g= ; X-YMail-OSG: 8pSd8v4VM1nul.9axSRiNOCa33.vUHPk0M8uozYIG9HYrXYN7Nc7y3XjCgn_pEQtWwWIyWQIy6qeastjvL.4rmr10yIGmhsQpel4OidbVZpdOYO2ZUbYZWDxoEpzheQS2YwYT2jwVHLSwkPSCzl09UcxD34R_pEOjzQXvVjoCJwdkdLm7GX8FpW9T6IqSrrD3r8ulFgr8zxx_HtQyCZiKVoZUg-- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issue 13135 -- SBVR RTF issue Date: Tue, 24 Feb 2009 11:17:04 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmDLcsK7MTD1CSdTUi6b88u9Te/vATQxifw Ed, I have followed your suggestion by using Option 1 and including your less technically worded version of Option 2 as a second paragraph in the Note in Option 1. Donald -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: 30 January 2009 22:53 To: sbvr-rtf@omg.org Subject: Re: issue 13135 -- SBVR RTF issue Donald Chapin wrote: > Attached is the Issue 13135 resolution which was agreed at the SBVR RTF face > to face meeting, subject to simpler wording to be provided by Don Baisley. > > > > We need to: > > a. Decide on which of the two wording options is most clear. > > b. Decide if clarifying wording needs to go in Annex D or else where. I attach a marked-up version. I think the beginning of Don's Option 2 text answers the question that was uppermost in the minds of the people who raised the issue, and to that end, I have suggested some additional text for the Note that is the end of Option 1. OTOH, I don't really like Option 2 because it is too technical in areas where Option 1 (by being less pedantic) is easier to understand, and because its phrasing of the missing concept suggests a notation (R ranges over T1 or T2) that isn't supported by SBVR SE. You can see from the text I propose what that formulation really has to look like. Underlying this is the fact that SBVR says you can define a concept as a union of other concepts, but doesn't actually provide a formulation for that in clause 9 (it can, of course, be phrased as the obvious projection) nor a keyword for that in Annex C. -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." Issue 13135 Resolution 2009-02-24.doc From: Don Baisley To: "'SBVR RTF'" Date: Tue, 24 Feb 2009 09:42:45 -0800 Subject: RE: issue 13135 -- SBVR RTF issue Thread-Topic: RE: issue 13135 -- SBVR RTF issue Thread-Index: AcmWp00LPMg6yejEQDiEaD0xSGqjQQ== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US The proposed issue resolution included the following statement in a note: If more that one role ranges over object type fact type is specified for the same role in a given body of shared meanings, then only things that are instances of both object types can play the role that ranges over the object types. The statement has problems: 1. .that. should be .than.. 2. .more than one. does not align with .both.. 3. .more than one role ranges over object type fact type. makes no sense because there is only one .role ranges over object type. fact type. We are talking about ranging over multiple object types. We are not talking about multiple fact types. The statement should be simplified as follows, which I have done in the attached document with change-tracking turned on. If a role ranges over multiple object types, then everything that plays the role is an instance of each of those object types. Best regards, Don Issue 13135 Resolution 2009-02-241.doc Subject: RE: issue 13135 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Tue, 24 Feb 2009 15:28:55 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 02/24/2009 15:28:58 OK with me, except that there is a typo in the new note. "If more that one role ranges over object type fact type ..." should read "If more than one role ranges over object type fact type ..." -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:In-Reply-To:Thread-Index:X-MIMEOLE; b=2saTDHhr1CQTyJq6WEAV/sPgyLSzfvnA7+Jd89INPosGhpRc3uMWqI0qYs9J3C7b85TvIZL5we7q2Uv551AyuSkfOjJQVG/GCwrr9MLVTYFetxInO2XUeyXUPiVNmEqf/42ViqhayM40rdPdwdXC9A1WlBRqGNZ1Z10sdiH4Uyc= ; X-YMail-OSG: vhk9fwUVM1m_Ia9ZgzPsH1LCj_oo8DBhPmUkN.EucAgZYjx.fjHXH3bfDYMFVv17reNurIuOjS0mWbqkTGesGR7rgkCFDjSVgx6_T7CJ2e2iTJTBePPY5rVIVLgJ_M.l4JBM82i5n2gU01vFAAfX2R5Lgcj6wquTcDvJLlLD1VWI3myue2EMG4h3B0gbP0U- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'SBVR RTF'" Subject: RE: issue 13135 -- SBVR RTF issue Date: Wed, 25 Feb 2009 17:38:13 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmWp00LPMg6yejEQDiEaD0xSGqjQQAxtKFA I.ve included Don.s clarification of the sentence pointed out in his email below in the attached revised resolution to Issue 13135 with one change. Since role ranges over object type is about specifying which object type instances can play a given role and not about specifying which things can be instances of given object types, I have revised Don.s suggested sentence to reflect that. Also the typo Mark pointed out is fixed (deleted). Donald -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: 24 February 2009 17:43 To: 'SBVR RTF' Subject: RE: issue 13135 -- SBVR RTF issue The proposed issue resolution included the following statement in a note: If more that one role ranges over object type fact type is specified for the same role in a given body of shared meanings, then only things that are instances of both object types can play the role that ranges over the object types. The statement has problems: 1. .that. should be .than.. 2. .more than one. does not align with .both.. 3. .more than one role ranges over object type fact type. makes no sense because there is only one .role ranges over object type. fact type. We are talking about ranging over multiple object types. We are not talking about multiple fact types. The statement should be simplified as follows, which I have done in the attached document with change-tracking turned on. If a role ranges over multiple object types, then everything that plays the role is an instance of each of those object types. Best regards, Don Issue 13135 Resolution 2009-02-25.doc User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 25 Feb 2009 08:33:59 -1000 Subject: Re: issue 13135 -- SBVR RTF issue From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: issue 13135 -- SBVR RTF issue Thread-Index: AcmWp00LPMg6yejEQDiEaD0xSGqjQQAxtKFAAAJf/Vw= Donald, I want to confirm that the wording in the new 2nd paragraph of the note (shown on p. 2 of the Resolution), which uses terms 'specify' and 'define', does not conflict with what is said in the first bits being added (shown on p. 1 of the Resolution), namely: .Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types.. In other words, an "anonymous" object type would not be defined/specified, in the sense of needing to make a vocabulary entry for it, right? (For example, we could have the role 'customer' that ranges over person and organization, with the interpretation that, indeed, there is an anonymous object type that is "person or organization" but the business person does not need to create a term such as "person or organization" with a vocabulary entry to cover it.) Regards, Keri On 2/25/09 7:38 AM, "Donald Chapin" wrote: I.ve included Don.s clarification of the sentence pointed out in his email below in the attached revised resolution to Issue 13135 with one change. Since role ranges over object type is about specifying which object type instances can play a given role and not about specifying which things can be instances of given object types, I have revised Don.s suggested sentence to reflect that. Also the typo Mark pointed out is fixed (deleted). Donald -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: 24 February 2009 17:43 To: 'SBVR RTF' Subject: RE: issue 13135 -- SBVR RTF issue The proposed issue resolution included the following statement in a note: If more that one role ranges over object type fact type is specified for the same role in a given body of shared meanings, then only things that are instances of both object types can play the role that ranges over the object types. The statement has problems: 1. .that. should be .than.. 2. .more than one. does not align with .both.. 3. .more than one role ranges over object type fact type. makes no sense because there is only one .role ranges over object type. fact type. We are talking about ranging over multiple object types. We are not talking about multiple fact types. The statement should be simplified as follows, which I have done in the attached document with change-tracking turned on. If a role ranges over multiple object types, then everything that plays the role is an instance of each of those object types. Best regards, Don Date: Wed, 25 Feb 2009 19:50:32 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: keri CC: "Donald R. Chapin" , SBVR RTF Subject: Re: issue 13135 -- SBVR RTF issue Keri, I was just about to send this when your email arrived ... The second part of the 'Note' entry says "Alternatively one can first define an object type that is that union, e.g., TU defined as .T1 or T2 or T3., and then specify that the role ranges over that type, e.g., R ranges over TU." .T1 or T2 or T3. is an extensional definition of the concept of the union. A definition is substitutable for a term, and you can use the definition to refer to the concept without creating a term. I agree that the union has to be defined. But isn't it sufficient to embed the extensional definition in the 'ranges over' fact type? Regards, John keri wrote: Donald, I want to confirm that the wording in the new 2nd paragraph of the note (shown on p. 2 of the Resolution), which uses terms 'specify' and 'define', does not conflict with what is said in the first bits being added (shown on p. 1 of the Resolution), namely: .Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types.. In other words, an "anonymous" object type would not be defined/specified, in the sense of needing to make a vocabulary entry for it, right? (For example, we could have the role 'customer' that ranges over person and organization, with the interpretation that, indeed, there is an anonymous object type that is "person or organization" but the business person does not need to create a term such as "person or organization" with a vocabulary entry to cover it.) Regards, Keri On 2/25/09 7:38 AM, "Donald Chapin" wrote: I.ve included Don.s clarification of the sentence pointed out in his email below in the attached revised resolution to Issue 13135 with one change. Since role ranges over object type is about specifying which object type instances can play a given role and not about specifying which things can be instances of given object types, I have revised Don.s suggested sentence to reflect that. Also the typo Mark pointed out is fixed (deleted). Donald -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: 24 February 2009 17:43 To: 'SBVR RTF' Subject: RE: issue 13135 -- SBVR RTF issue The proposed issue resolution included the following statement in a note: If more that one role ranges over object type fact type is specified for the same role in a given body of shared meanings, then only things that are instances of both object types can play the role that ranges over the object types. The statement has problems: 1. .that. should be .than.. 2. .more than one. does not align with .both.. 3. .more than one role ranges over object type fact type. makes no sense because there is only one .role ranges over object type. fact type. We are talking about ranging over multiple object types. We are not talking about multiple fact types. The statement should be simplified as follows, which I have done in the attached document with change-tracking turned on. If a role ranges over multiple object types, then everything that plays the role is an instance of each of those object types. Best regards, Don From: Don Baisley To: "Donald.Chapin@btinternet.com" , "'SBVR RTF'" Date: Wed, 25 Feb 2009 11:42:54 -0800 Subject: RE: issue 13135 -- SBVR RTF issue Thread-Topic: issue 13135 -- SBVR RTF issue Thread-Index: AcmWp00LPMg6yejEQDiEaD0xSGqjQQAxtKFAAARptYA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Donald, Your first change, which replaces .plays. with .is an instance of., is fine. Given that change, the phrase can be shortened by removing .thing that is an., which contributes nothing. Your second change, which replaces .is. with .must be., is incorrect because it adds the modality of obligation. The correct modality is necessity. You could instead replace .is. with .is necessarily.. In conclusion: If a role ranges over multiple object types, then every instance of the role is necessarily an instance of each of those object types. Best regards, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Wednesday, February 25, 2009 9:38 AM To: 'SBVR RTF' Subject: RE: issue 13135 -- SBVR RTF issue I.ve included Don.s clarification of the sentence pointed out in his email below in the attached revised resolution to Issue 13135 with one change. Since role ranges over object type is about specifying which object type instances can play a given role and not about specifying which things can be instances of given object types, I have revised Don.s suggested sentence to reflect that. Also the typo Mark pointed out is fixed (deleted). Donald -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: 24 February 2009 17:43 To: 'SBVR RTF' Subject: RE: issue 13135 -- SBVR RTF issue The proposed issue resolution included the following statement in a note: If more that one role ranges over object type fact type is specified for the same role in a given body of shared meanings, then only things that are instances of both object types can play the role that ranges over the object types. The statement has problems: 1. .that. should be .than.. 2. .more than one. does not align with .both.. 3. .more than one role ranges over object type fact type. makes no sense because there is only one .role ranges over object type. fact type. We are talking about ranging over multiple object types. We are not talking about multiple fact types. The statement should be simplified as follows, which I have done in the attached document with change-tracking turned on. If a role ranges over multiple object types, then everything that plays the role is an instance of each of those object types. Best regards, Don To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: RE: SBVR Issue: can a role range over multiple object types Date: Wed, 3 Dec 2008 21:13:04 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: can a role range over multiple object types thread-index: AclVgMwfGmVOHW6nToaYQrecAjz/WQAAsA3s From: "Sjir Nijssen" To: "Mark H Linehan" , Dera Mark, I am strongly in favour of your proposal. We have implemented this already as we agree with you that "it does not make sense" to have a role range over more than one object type". Thanks for this proposal. Kind regards Sjir -------------------------------------------------------------------------------- Van: Mark H Linehan [mailto:mlinehan@us.ibm.com] Verzonden: wo 3-12-2008 20:51 Aan: sbvr-rtf@omg.org Onderwerp: SBVR Issue: can a role range over multiple object types The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: RE: SBVR Issue: can a role range over multiple object types Date: Wed, 3 Dec 2008 13:22:45 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclVgMwfGmVOHW6nToaYQrecAjz/WQAAsA3sAAAcq5A= From: "Terry Halpin" To: "Sjir Nijssen" , "Mark H Linehan" , Dear Mark I agree with Sjir to restrict fact roles to range over only one object type. Below is part of a communication I sent to Donald Chapin recently to clarify my position on the issue. <> Cheers Terry From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: Wednesday, December 03, 2008 1:13 PM To: Mark H Linehan; sbvr-rtf@omg.org Subject: RE: SBVR Issue: can a role range over multiple object types Dera Mark, I am strongly in favour of your proposal. We have implemented this already as we agree with you that "it does not make sense" to have a role range over more than one object type". Thanks for this proposal. Kind regards Sjir -------------------------------------------------------------------------------- Van: Mark H Linehan [mailto:mlinehan@us.ibm.com] Verzonden: wo 3-12-2008 20:51 Aan: sbvr-rtf@omg.org Onderwerp: SBVR Issue: can a role range over multiple object types The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: "Nikolai Mansourov" To: , Subject: RE: issue 13135 -- SBVR RTF issue Date: Wed, 3 Dec 2008 15:31:42 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclVgoMT0PKsCWVfR5Wc3d5PDQUOIgAArxPA X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hello all, I favor the solution to restrict the role to a single object type by introducing a Necessity: "each role ranges over exactly one object type". I do not believe that the SBVR specification should explain what it means for a role to range over multiple object types (as at the level of the SBVR specification this is somewhat straight forward), however, if needed, it is the vocabulary being defined should introduce a single super type for multiple object types that the role in question can range over, AND provide the explanation why this is done for the business that this vocabulary represents. In other words, the explanation has to be pushed down from the SBVR specification to the vocabulary being defined. I agree with the implementation concerns being raised for multiple object types per role. Best regards, Nick -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 3:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-Authority-Analysis: v=1.0 c=1 a=Gp156JHarEkA:10 a=d_nv_tyJmmkA:10 a=1R_UTxeyfPHezGELZkMA:9 a=9fggUe_AWI7Bix01Xb0A:7 a=PCflact6y-ciCHb09u6kWIsLrJIA:4 a=frGiPHrGPy0A:10 a=s34t66kMxTcA:10 a=tsIYq3Wo7I0A:10 a=X87BalrooHN_nIC845MA:9 a=mtfuvgxrLBJQnZErhr0A:7 a=CwVlDeaBfFYDXyj9nw4gEMfj-q4A:4 a=Sz-0p1zU2dQA:10 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 03 Dec 2008 10:53:30 -1000 Subject: Re: SBVR Issue: can a role range over multiple object types From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclViTJTcPNJssF8Ed2HiwARJM+Cgg== FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility . where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 03 Dec 2008 15:56:30 -0600 To: keri , Mark H Linehan , SBVR RTF From: "Ronald G. Ross" Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: RE: SBVR Issue: can a role range over multiple object types Date: Wed, 3 Dec 2008 15:36:57 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclVkiJXeMQzwsmKSx6hqWNNF9QCbwABHaWA From: "Terry Halpin" To: "Ronald G. Ross" , "keri" , "Mark H Linehan" , "SBVR RTF" My earlier response seems to have been lost, but at any rate, there is a difference between a fact-role (e.g. the employs role in Company employs Person) and a role subtype (e.g. Gun as a subtype of Weapon). I thought the .Role ranges over ObjectType. association was intended for fact-roles only, but perhaps this is not the case. However it is still useful to distinguish fact-roles in different fact types, even if one fact type is a specialization of the other (e.g. you often want to assert different constraints on these roles). So I support the wish to have each fact-role range over exactly one fact type. Cheers Terry From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 2:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: Re: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 19:45:55 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 19:45:57 As pointed out by Nick Mansourov, one can define weapon as: "gun or knife or umbrella". Presuming your basic fact type is something like "thing brought into facility", then your rule could be "No weapon may be brought into a GH Facility". I'm not sure of how you intend to write a rule about things that are spontaneously used as weapons. You could have an intentional definition of "weapon" in terms of how it gets used. Maybe "weapon: thing that is used to strike a person". But then anything can be brought into a weapon -- even a gun -- if it isn't actually used to strike a person. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/03/2008 04:56 PM To keri , Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com pic18483.gif X-MailScanner-Watermark: 1228959165.0663@MMM9BRWMH1MdGP6b5OIGlw Date: Wed, 03 Dec 2008 20:32:41 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: keri CC: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: mB41WggV019647 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Keri wrote: > As I understand things, this fact type ('role ranges over object type') is > intended to cover both categories of role (fact type role and, as termed in > Clause 11, 'situational' role). ... and the examples Ron and I gave are for > cases of 'situational role'. There is an important semantic issue here, and SBVR has painted over it. I agree with Keri that 'role ranges over fact type' was intended by some to apply to both 'fact type role' (which is well-defined), and 'situational role' (which is not). Terry wrote: >> I thought the Role ranges over ObjectType association was intended for >> fact-roles only, but perhaps this is not the case. That case is well-defined. And we apparently want to require: Each fact type role ranges over exactly one object type. If I accept the notion that a 'situational role' is an unspecified relationship to an unspecified thing, then it is a fact type role in some unidentified fact type. And it would be constrained to one object type if we only knew what the fact type was. Alternatively, if I see it as an abstraction of several (related) fact type roles, whether actual or potential, then it is an object type, and those fact type roles somehow create its delimiting characteristics. And many things can be instances of an abstract object type in a given world, without any of those properties being intrinsic in any of the things. An umbrella can be a 'weapon' because it has the necessary properties. If one of the properties is that it must be, or have been, used to inflict damage on persons, then only some umbrellas are weapons -- the Venn diagram is "overlap", and there is NO formal relationship between the class 'umbrella' and the class 'weapon'. If, OTOH, one of the properties is that it *can be used* to inflict damage on persons, then all umbrellas are weapons, and the formal relationship between the classes is specialization, even if we only recognize that by implication. The point is that if you don't define the properties of the object type 'weapon', the term doesn't mean anything. And if you define the properties of 'weapon', I may be able to infer from the properties of umbrella that every umbrella is a weapon, or not. In any case, however, these relationships are among object types defined by properties, and have nothing directly to do with fact type roles. A fact type role is played by things in states of affairs -- it has no meaning outside those states of affairs. A thing that plays that role is not an instance of the role in any world larger than that state of affairs, excluding all others. A situational role is a category of things in a given world. In that world, a given thing either satisfies the required properties or it does not. (It does not 'sometimes satisfy'; a world is static -- other times are different worlds.) The question at hand is whether SBVR should restrict a fact type role to things of one object type. We take it as a given that a situational role (object type) can subsume one or more object types, exclude one or more object types, and have no well-defined relationship to other object types. Terry wrote: >> However it is still useful to distinguish fact-roles in different fact types, >> even if one fact type is a specialization of the other (e.g. you often want to >> assert different constraints on these roles). >> So I support the wish to have each fact-role range over exactly one fact type. That is a different question. I have to agree. A fact-type role is defined for a particular fact type. The problem we see (and confuse) in SBVR is that two distinct fact type roles can have exactly the same definition with respect to different verbs. Properly those are homonyms, and we mistake them for a single designation. So for example, we use the same rolename 'maximum cardinality' in defining 1-to-n quantification and in defining m-to-n quantification. Those are two different fact type roles, which have the same signifier, and the same text definition, but the definition carefully avoids identifying the verb to which it applies. If the definition were clearly worded, it would be clear that we have homonyms. -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." DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:In-Reply-To:Thread-Index; b=gYPgsYYyT+bb3pmlf9dNu+VO3zVrvJSaQZbKa2MroNWiyyizTZIM5RmgLRZc8j4uxRPlqRZsssY3PKgJfNQlXqPcv210D5+bmwtJphizxe8Ia94pJlGhBmEtB7S7iGUImW0Np3c05qY2FIoRAUq8lurkLZ9g0sqEbc4Zao1Nruw= ; X-YMail-OSG: 0hjeSAMVM1n00mvl06vqxOi4SY.yQzcODynfEi5UbqpfaZkqPh2UGcDTP8u3V.xo6r1bTdtYpXrUNSZq6TQ39Q7WpJC0XToE8WVO1LVAmSd.Hj8h.jTDOlcu1GMMDufOQu3A4QfVauYVaqbOMM87EylSk9f3cDDkdyvRKM29YoJ0oRiUfmA2wfG_FW4- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issue 13135 -- SBVR RTF issue -- Importance of Being Very Clear about Context of Discussion Points Date: Thu, 4 Dec 2008 08:34:56 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclVgnVenJn9ZR2ZT9ucwVltVfJQrAAZDC1Q All . There is quite a bit of confusion surrounding this Issue. It would be very helpful, both for orderly discussion and coming to a consensus resolution, for each point in emails discussing this Issue to be put clearly in the specific context of either (or both) alternative in all four of the following dimensions: 1. Definition or Use (especially in definitions and statements) a. Defining what roles can range over (.role defined to range over by object type.) vs. b. Referencing/using object types whose instances the role does range over within the given definition in 1a.; e.g. subcategories of the object type in 1a. (.role ranges over object type.) 2. SBVR or its formal interpretation a. The linguistic meaning/definition-centric dictionary vocabulary of Clause 8, 9 11 & 12 vs. b. The vocabulary in the Clause 10.1.1 formal semantics (interpretation) for SBVR 3. .Fact type role. or .situational role. a. .fact type role ranges over object type. vs. b. .situational role ranges over object type. 4. .General concept. as adopted from ISO or ORM .object type. a. .role ranges over general concept. (as general concept is adopted from ISO 1087-1) vs. b. .role ranges over type of individual. (type of individual is the term used in the Clause 10.1.1 formal semantics and is a synonym for ORM object type) It is also important to remember that SBVR is four vocabularies for business vocabulary and business rules and a metamodel for interchanging business vocabularies and business rules. SBVR is not a metamodel for an SBVR tool. There are tool requirements and software design transformations between SBVR and any tool metamodel. Tool design should not constrain the vocabulary of the discipline of specifying business vocabulary and business rules as corporate assets. Many Thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 8:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 04 Dec 2008 10:05:27 -0600 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: SBVR Issue: can a role range over multiple object types At 06:45 PM 12/3/2008, Mark H Linehan wrote: As pointed out by Nick Mansourov, one can define weapon as: "gun or knife or umbrella". Presuming your basic fact type is something like "thing brought into facility", then your rule could be "No weapon may be brought into a GH Facility". I'm not sure of how you intend to write a rule about things that are spontaneously used as weapons. You could have an intentional definition of "weapon" in terms of how it gets used. Maybe "weapon: thing that is used to strike a person". But then anything can be brought into a weapon -- even a gun -- if it isn't actually used to strike a person. brick ... "building material [weapon] is used in assault" key ... "personal item [weapon] is used in assault" baseball bat ... "sports equipment [weapon] is used in assault" fire extinguisher ... "safety item [weapon] is used in assault" vehicle ... "vehicle [weapon] is used in assault" (non-guard) dog ... "pet [weapon] is used in assault" Rule: The annual safety certification for a city must evaluate each weapon used in an assault in that city during that year. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/03/2008 04:56 PM To keri , Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: "Nikolai Mansourov" To: "'Ronald G. Ross'" , "'keri'" , "'Mark H Linehan'" , "'SBVR RTF'" Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 11:09:52 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclVkhv+i8llstpkQZq/SzmKfxu3fgAk+QUg X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: Re: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Thu, 4 Dec 2008 11:31:43 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/04/2008 11:31:43 So you can have a concept called "weapon" whose definition gets updated yearly to include whatever things are considered weapons this year. The business semantic is "we understand weapons to be bricks or keys or baseball bats or ...." And we forbid the bringing of any weapon into a Group Health Facility. It seems to me that separating the concept of "what a weapon is" from the concept "person brings weapon into facility" makes for a more understandable organization. I agree with Nick when he says "Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use ..concept specialises concept.. and ..concept is coextensive with concept... The secondary mechanism is to use multiple object types in ..role ranges over object type... It is ..secondary.. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation." But the most important point is that the spec currently leaves this whole issue open, making it likely that different vendors will interpret it in different ways. We can clean this up by saying that a role ranges only over one object type, or we can add a note that explains the semantics. We should do one or the other. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/04/2008 11:05 AM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR Issue: can a role range over multiple object types At 06:45 PM 12/3/2008, Mark H Linehan wrote: As pointed out by Nick Mansourov, one can define weapon as: "gun or knife or umbrella". Presuming your basic fact type is something like "thing brought into facility", then your rule could be "No weapon may be brought into a GH Facility". I'm not sure of how you intend to write a rule about things that are spontaneously used as weapons. You could have an intentional definition of "weapon" in terms of how it gets used. Maybe "weapon: thing that is used to strike a person". But then anything can be brought into a weapon -- even a gun -- if it isn't actually used to strike a person. brick ... "building material [weapon] is used in assault" key ... "personal item [weapon] is used in assault" baseball bat ... "sports equipment [weapon] is used in assault" fire extinguisher ... "safety item [weapon] is used in assault" vehicle ... "vehicle [weapon] is used in assault" (non-guard) dog ... "pet [weapon] is used in assault" Rule: The annual safety certification for a city must evaluate each weapon used in an assault in that city during that year. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/03/2008 04:56 PM To keri , Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility ­ where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com pic101132.gif X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 04 Dec 2008 10:41:16 -0600 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: SBVR Issue: can a role range over multiple object types At 10:31 AM 12/4/2008, Mark H Linehan wrote: So you can have a concept called "weapon" whose definition gets updated yearly to include whatever things are considered weapons this year. I don't think I would do it like that. I believe I would simply define "weapon" as "any thing that has been used in an assault". That's the real business meaning. By the way, I am talking only about situational role as it was discussed in Clause 11. Ron The business semantic is "we understand weapons to be bricks or keys or baseball bats or ...." And we forbid the bringing of any weapon into a Group Health Facility. It seems to me that separating the concept of "what a weapon is" from the concept "person brings weapon into facility" makes for a more understandable organization. I agree with Nick when he says "Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use ..concept specialises concept.. and ..concept is coextensive with concept... The secondary mechanism is to use multiple object types in ..role ranges over object type... It is ..secondary.. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation." But the most important point is that the spec currently leaves this whole issue open, making it likely that different vendors will interpret it in different ways. We can clean this up by saying that a role ranges only over one object type, or we can add a note that explains the semantics. We should do one or the other. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/04/2008 11:05 AM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR Issue: can a role range over multiple object types At 06:45 PM 12/3/2008, Mark H Linehan wrote: As pointed out by Nick Mansourov, one can define weapon as: "gun or knife or umbrella". Presuming your basic fact type is something like "thing brought into facility", then your rule could be "No weapon may be brought into a GH Facility". I'm not sure of how you intend to write a rule about things that are spontaneously used as weapons. You could have an intentional definition of "weapon" in terms of how it gets used. Maybe "weapon: thing that is used to strike a person". But then anything can be brought into a weapon -- even a gun -- if it isn't actually used to strike a person. brick ... "building material [weapon] is used in assault" key ... "personal item [weapon] is used in assault" baseball bat ... "sports equipment [weapon] is used in assault" fire extinguisher ... "safety item [weapon] is used in assault" vehicle ... "vehicle [weapon] is used in assault" (non-guard) dog ... "pet [weapon] is used in assault" Rule: The annual safety certification for a city must evaluate each weapon used in an assault in that city during that year. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/03/2008 04:56 PM To keri , Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility ­ where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: "Nikolai Mansourov" To: "'Mark H Linehan'" , Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 11:49:49 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWLf1NFEwlt1wDR3yX4plxXfuykQAAG9Ww X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Oh, what an interesting point you are making Mark ! I don.t believe, that there is going to be a yearly update definition of the .concept. .weapon. in the sense of a DIRECT ENUMERATION of all .things. that ARE .weapons., because things are USED as .weapons.. As per Merriam-Webster: a weapon is 1. something (as a club, knife, or gun) used to injure, defeat, or destroy 2 : a means of contending against another So, .Weapon. is a .noun concept., however, the question may be: is .weapon. a .role., an .object type. or a .facttype role. ? As I think about this answer to this question, I see another potential problem with the definitions of .object type. and hence the .role ranges over an object type.. From a formal modeling perspective, .object type. and .role. are two distinct subclasses of a .noun concept., which justifies the above question. Does this define a segmentation (are the categories of .role. and .object type. disjoint ) ? Note that the .role ranges over object type. specifically uses .object type. subclass. I would argue that a .weapon. is a .role. rather than an .object type.. Intuitively, an .object type. may be something that I can (at least potentially) define via a yearly updated enumeration of all things that belong to the extension of the corresponding concept. On the other hand, a .role. is something that can not be defined in this way. Does the standing definition of the .object type. convey this intuitive meaning ? [.object type. is defines as .a noun concept that classifies things on the basis of their common characteristics..] I would argue, that within the scope of a facttype "No weapon may be brought into a GH Facility", the .facttype role. .weapon. ranges over a .role. .weapon. Does this mean that we ought to change the destination of .role ranges over. from .object type. to .noun concept. ? A .factype role. then will be able to .range over. a .role.. In my opinion, this is definitely going to solve the technical issue of having two mechanisms for subclassing. Am I off the track here completely ? Best regards, Nick -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Thursday, December 04, 2008 11:32 AM To: sbvr-rtf@omg.org Subject: Re: SBVR Issue: can a role range over multiple object types So you can have a concept called "weapon" whose definition gets updated yearly to include whatever things are considered weapons this year. The business semantic is "we understand weapons to be bricks or keys or baseball bats or ...." And we forbid the bringing of any weapon into a Group Health Facility. It seems to me that separating the concept of "what a weapon is" from the concept "person brings weapon into facility" makes for a more understandable organization. I agree with Nick when he says "Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation." But the most important point is that the spec currently leaves this whole issue open, making it likely that different vendors will interpret it in different ways. We can clean this up by saying that a role ranges only over one object type, or we can add a note that explains the semantics. We should do one or the other. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/04/2008 11:05 AM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR Issue: can a role range over multiple object types At 06:45 PM 12/3/2008, Mark H Linehan wrote: As pointed out by Nick Mansourov, one can define weapon as: "gun or knife or umbrella". Presuming your basic fact type is something like "thing brought into facility", then your rule could be "No weapon may be brought into a GH Facility". I'm not sure of how you intend to write a rule about things that are spontaneously used as weapons. You could have an intentional definition of "weapon" in terms of how it gets used. Maybe "weapon: thing that is used to strike a person". But then anything can be brought into a weapon -- even a gun -- if it isn't actually used to strike a person. brick ... "building material [weapon] is used in assault" key ... "personal item [weapon] is used in assault" baseball bat ... "sports equipment [weapon] is used in assault" fire extinguisher ... "safety item [weapon] is used in assault" vehicle ... "vehicle [weapon] is used in assault" (non-guard) dog ... "pet [weapon] is used in assault" Rule: The annual safety certification for a city must evaluate each weapon used in an assault in that city during that year. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" "Ronald G. Ross" 12/03/2008 04:56 PM To keri , Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Date: Thu, 04 Dec 2008 18:01:59 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Nikolai Mansourov CC: "'SBVR RTF'" Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: "Nikolai Mansourov" To: "'SBVR RTF'" , Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 12:08:27 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclVsEjBPD/Qnr+iQUKsgSNOaNuDrAAgIa8w X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hello all, A 'situational role' that specializes both the 'object type' and a 'role' [an object type that corresponds to things based on their playing a part, assuming a function, or being used in some situation] seems appropriate to me. In computer science (e.g. Java language) a difference is being made between a class and an interface: classes specialize other classes and at the same time a class can implement a certain interface. From our perspective both define a 'noun concept', however a class is something you can 'instantiate', and once you've done that, you can use its interface. Is there a similar distinction between an 'object type' and a 'role' or only between an 'object type' and a 'situational role' ? As I mentioned earlier, in some intuitive sense an 'object type' vs 'role' seems to make this exact distinction ("first of all, this thing IS an 'umbrella' and by the way, it was USED as a weapon"; you instantiate a thing as an umbrella, first use it to provide protection from precipitation, then use it to provide extra support when walking, an finally use it a weapon). Why 'situational role' is only part of 'Business Vocabulary' and not part of MRV ? Still, it seems to make sense to define a 'weapon' as a 'role' or a 'situational role' and upgrade the destination of 'role ranges over' from 'object type' to 'noun concept'. Cheers, Nick -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, December 03, 2008 8:33 PM To: keri Cc: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types Keri wrote: > As I understand things, this fact type ('role ranges over object type') is > intended to cover both categories of role (fact type role and, as termed in > Clause 11, 'situational' role). ... and the examples Ron and I gave are for > cases of 'situational role'. There is an important semantic issue here, and SBVR has painted over it. I agree with Keri that 'role ranges over fact type' was intended by some to apply to both 'fact type role' (which is well-defined), and 'situational role' (which is not). Terry wrote: >> I thought the "Role ranges over ObjectType" association was intended for >> fact-roles only, but perhaps this is not the case. That case is well-defined. And we apparently want to require: Each fact type role ranges over exactly one object type. If I accept the notion that a 'situational role' is an unspecified relationship to an unspecified thing, then it is a fact type role in some unidentified fact type. And it would be constrained to one object type if we only knew what the fact type was. Alternatively, if I see it as an abstraction of several (related) fact type roles, whether actual or potential, then it is an object type, and those fact type roles somehow create its delimiting characteristics. And many things can be instances of an abstract object type in a given world, without any of those properties being intrinsic in any of the things. An umbrella can be a 'weapon' because it has the necessary properties. If one of the properties is that it must be, or have been, used to inflict damage on persons, then only some umbrellas are weapons -- the Venn diagram is "overlap", and there is NO formal relationship between the class 'umbrella' and the class 'weapon'. If, OTOH, one of the properties is that it *can be used* to inflict damage on persons, then all umbrellas are weapons, and the formal relationship between the classes is specialization, even if we only recognize that by implication. The point is that if you don't define the properties of the object type 'weapon', the term doesn't mean anything. And if you define the properties of 'weapon', I may be able to infer from the properties of umbrella that every umbrella is a weapon, or not. In any case, however, these relationships are among object types defined by properties, and have nothing directly to do with fact type roles. A fact type role is played by things in states of affairs -- it has no meaning outside those states of affairs. A thing that plays that role is not an instance of the role in any world larger than that state of affairs, excluding all others. A situational role is a category of things in a given world. In that world, a given thing either satisfies the required properties or it does not. (It does not 'sometimes satisfy'; a world is static -- other times are different worlds.) The question at hand is whether SBVR should restrict a fact type role to things of one object type. We take it as a given that a situational role (object type) can subsume one or more object types, exclude one or more object types, and have no well-defined relationship to other object types. Terry wrote: >> However it is still useful to distinguish fact-roles in different fact types, >> even if one fact type is a specialization of the other (e.g. you often want to >> assert different constraints on these roles). >> So I support the wish to have each fact-role range over exactly one fact type. That is a different question. I have to agree. A fact-type role is defined for a particular fact type. The problem we see (and confuse) in SBVR is that two distinct fact type roles can have exactly the same definition with respect to different verbs. Properly those are homonyms, and we mistake them for a single designation. So for example, we use the same rolename 'maximum cardinality' in defining 1-to-n quantification and in defining m-to-n quantification. Those are two different fact type roles, which have the same signifier, and the same text definition, but the definition carefully avoids identifying the verb to which it applies. If the definition were clearly worded, it would be clear that we have homonyms. -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: "Nikolai Mansourov" To: , "'SBVR RTF'" , "'Mark H Linehan'" Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 12:46:08 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWMhqEKrVj9h69TUiy4VKN23/Q9wAAQGjQ X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hi John, Your point is well taken. Actually, I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive). Let.s say in my report I want to capture both definitions of a .weapon. (both scenarios) and provide some connection between them. I want to define an object type .weapon-that-can-be-identified. as an .object type. as a list of .firearm, knife, umbrella, nailclipper, bottled water.; provide an element of guidance that .it is obligatory that the list of weapon-that-can-be-identified shall be reviewed at least annually.; define the rule that .No weapon may be brought into a GH Facility. in the sense that .it is prohibited to bring a weapon-that-can-be-identified into a GH facility. and also define a .Merriam-Webster-weapon. in the Merriam-Webster sense as .anything that can be used to injure another person.; and establish the rationale for the .No weapon. rule, in the sense that .the .no weapon. rule is introduced to reasonably restrict the availability of weapon in facilities.. In the context of a facttype, .weapon. is a factyype role. I should then provide a .facttype role ranges over. relation to some sort of a definition of the .Merriam-Webster-weapon.. My question is what SBVR modeling element do I use to represent a .Merriam-Webster-weapon. ? In terms of compliance points, can I use the .Meaning and Representaion Vocabulary. to do that, or I need to use .Business Vocabulary. ? .Situational role. is part of the .Business Vocabulary., and not part of the MRV. How do I express the second scenario in MRV ? Can I define a .role. .Merriam-Webster-weapon. as .anything that can be used to injure a person. and use it as the destination of .facttype weapon ranges over role Merriam-Webster-weapon. ? Cheers, Nick -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Thursday, December 04, 2008 12:02 PM To: Nikolai Mansourov Cc: 'SBVR RTF' Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: "Nikolai Mansourov" To: "'SBVR RTF'" Subject: Multiple roles discussion and SBVR tools Date: Thu, 4 Dec 2008 12:56:38 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWOaeiCiEkNRq/RqmRF25KFgcntw== X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hello all, I want to emphasize the fact that the ongoing discussion about the .multiple roles, etc.. is very important from the SBVR tool perspective, like the MDT-SBVR open source Eclipse project, and the KDM Analytics SBVR environment. These tools provide an implementation for the SBVR metamodel by providing a mapping to the concrete Java classes as well as other concrete objects. From this perspective, the question .which exactly SBVR element do I use. is the key one. Also the question of .is this subclass hierarchy in the SBVR metamodel a disjoint one. is also very important. So please bear with us. Cheers, Nikolai Mansourov Chief Technology Officer KDM Analytics cell (613) 276-2323 www.kdmanalytics.com e-mail: nick@kdmanalytics.com Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 09:58:22 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWMhqEKrVj9h69TUiy4VKN23/Q9wAAQGjQAAF9roA= Priority: Non-Urgent From: "Paul Vincent" To: "Nikolai Mansourov" , , "SBVR RTF" , "Mark H Linehan" X-OriginalArrivalTime: 04 Dec 2008 17:58:27.0059 (UTC) FILETIME=[E87FE430:01C95639] .. I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive).. Surely the usual meaning here would be to entitle the security guard / receptionist to define .weapon. on a case by case basis? (ie the 2nd case). The rule is defined to be enforced on an ad hoc / judgement basis. e.g.1: Mad-looking man enters facility swinging a tightly rolled up newspaper. e.g.2: Child enters facility in fancy dress complete with sword. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: Nikolai Mansourov [mailto:nick@kdmanalytics.com] Sent: 04 December 2008 17:46 To: john.hall@modelsys.com; 'SBVR RTF'; 'Mark H Linehan' Subject: RE: SBVR Issue: can a role range over multiple object types Hi John, Your point is well taken. Actually, I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive). Let.s say in my report I want to capture both definitions of a .weapon. (both scenarios) and provide some connection between them. I want to define an object type .weapon-that-can-be-identified. as an .object type. as a list of .firearm, knife, umbrella, nailclipper, bottled water.; provide an element of guidance that .it is obligatory that the list of weapon-that-can-be-identified shall be reviewed at least annually.; define the rule that .No weapon may be brought into a GH Facility. in the sense that .it is prohibited to bring a weapon-that-can-be-identified into a GH facility. and also define a .Merriam-Webster-weapon. in the Merriam-Webster sense as .anything that can be used to injure another person.; and establish the rationale for the .No weapon. rule, in the sense that .the .no weapon. rule is introduced to reasonably restrict the availability of weapon in facilities.. In the context of a facttype, .weapon. is a factyype role. I should then provide a .facttype role ranges over. relation to some sort of a definition of the .Merriam-Webster-weapon.. My question is what SBVR modeling element do I use to represent a .Merriam-Webster-weapon. ? In terms of compliance points, can I use the .Meaning and Representaion Vocabulary. to do that, or I need to use .Business Vocabulary. ? .Situational role. is part of the .Business Vocabulary., and not part of the MRV. How do I express the second scenario in MRV ? Can I define a .role. .Merriam-Webster-weapon. as .anything that can be used to injure a person. and use it as the destination of .facttype weapon ranges over role Merriam-Webster-weapon. ? Cheers, Nick -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Thursday, December 04, 2008 12:02 PM To: Nikolai Mansourov Cc: 'SBVR RTF' Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: RE: issue 13135 -- SBVR RTF issue -- Importance of Being Very Clear about Context of Discussion Points To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Thu, 4 Dec 2008 13:18:08 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/04/2008 13:18:07 Since I raised this issue, I'll (try to) respond to Donald's four dimensions. For dimension 1, my issue is about 1a, "Defining what roles can range over". For dimension 2, my issue was triggered by 2a, "The linguistic meaning/definition-centric dictionary vocabulary of Clause 8, 9 11 & 12". But I sure hope that 2a and 2b are consistent! And I notice this text in 10.1.1.2: "Instantiated roles of facts refer to individuals (such as ..Employee 123. or ..the sales department.). These individuals are considered as being of a particular type (such as ..Employee. or ..Department.) where type denotes ..set of possible individuals.. For dimension 3, I would observe that the spec does not have the two fact types suggested. There is only "role ranges over object type ". From the perspective of an implementor, changing this to the two fact types suggested below just complicates the world. Especially if a fact type role is constrained to range over exaclty one object type, but a situation role can range over multiple object types. Let's not do that. For dimension 4, I first note that "general concept" is a synonym for SBVR's "object type". Second, I note that I cannot find a definition of "type of individual" in the spec. And I don't have access to a definition of ORM's "object type". So I don't understand the distinction that you are making. Regarding the point that "Tool design should not constrain the vocabulary of the discipline of specifying business vocabulary and business rules as corporate assets." -- I agree with that point. The SBVR specification has lots of complexities that I understand and accept because they are justified by real-world examples. This particular issue is about a detail where the SBVR specification is silent and clarification is needed. If we agree that roles should be able to range over multiple object types, then so be it. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Donald Chapin" "Donald Chapin" 12/04/2008 03:34 AM Please respond to To cc Subject RE: issue 13135 -- SBVR RTF issue -- Importance of Being Very Clear about Context of Discussion Points All . There is quite a bit of confusion surrounding this Issue. It would be very helpful, both for orderly discussion and coming to a consensus resolution, for each point in emails discussing this Issue to be put clearly in the specific context of either (or both) alternative in all four of the following dimensions: 1. Definition or Use (especially in definitions and statements) a. Defining what roles can range over (..role defined to range over by object type.) vs. b. Referencing/using object types whose instances the role does range over within the given definition in 1a.; e.g. subcategories of the object type in 1a. (..role ranges over object type.) 2. SBVR or its formal interpretation a. The linguistic meaning/definition-centric dictionary vocabulary of Clause 8, 9 11 & 12 vs. b. The vocabulary in the Clause 10.1.1 formal semantics (interpretation) for SBVR 3. ..Fact type role.. or ..situational role.. a. ..fact type role ranges over object type. vs. b. ..situational role ranges over object type. 4. ..General concept.. as adopted from ISO or ORM ..object type.. a. ..role ranges over general concept. (as general concept is adopted from ISO 1087-1) vs. b. ..role ranges over type of individual. (type of individual is the term used in the Clause 10.1.1 formal semantics and is a synonym for ORM object type) It is also important to remember that SBVR is four vocabularies for business vocabulary and business rules and a metamodel for interchanging business vocabularies and business rules. SBVR is not a metamodel for an SBVR tool. There are tool requirements and software design transformations between SBVR and any tool metamodel. Tool design should not constrain the vocabulary of the discipline of specifying business vocabulary and business rules as corporate assets. Many Thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 8:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org pic23010.gif From: "Nikolai Mansourov" To: "'Paul Vincent'" , , "'SBVR RTF'" , "'Mark H Linehan'" Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 13:22:52 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWMhqEKrVj9h69TUiy4VKN23/Q9wAAQGjQAAF9roAAAIGkIA== X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hi Paul, I suggest we agree to the existence to two scenarios. It all depends on the bigger context, arguably in the context of high assurance systems, where the element of guidance in question is a requirement for a software-based agent, the 2nd scenario may be considered too ambiguous. Cheers, Nick -------------------------------------------------------------------------------- From: Paul Vincent [mailto:pvincent@tibco.com] Sent: Thursday, December 04, 2008 12:58 PM To: Nikolai Mansourov; john.hall@modelsys.com; SBVR RTF; Mark H Linehan Subject: RE: SBVR Issue: can a role range over multiple object types Importance: Low .. I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive).. Surely the usual meaning here would be to entitle the security guard / receptionist to define .weapon. on a case by case basis? (ie the 2nd case). The rule is defined to be enforced on an ad hoc / judgement basis. e.g.1: Mad-looking man enters facility swinging a tightly rolled up newspaper. e.g.2: Child enters facility in fancy dress complete with sword. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: Nikolai Mansourov [mailto:nick@kdmanalytics.com] Sent: 04 December 2008 17:46 To: john.hall@modelsys.com; 'SBVR RTF'; 'Mark H Linehan' Subject: RE: SBVR Issue: can a role range over multiple object types Hi John, Your point is well taken. Actually, I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive). Let.s say in my report I want to capture both definitions of a .weapon. (both scenarios) and provide some connection between them. I want to define an object type .weapon-that-can-be-identified. as an .object type. as a list of .firearm, knife, umbrella, nailclipper, bottled water.; provide an element of guidance that .it is obligatory that the list of weapon-that-can-be-identified shall be reviewed at least annually.; define the rule that .No weapon may be brought into a GH Facility. in the sense that .it is prohibited to bring a weapon-that-can-be-identified into a GH facility. and also define a .Merriam-Webster-weapon. in the Merriam-Webster sense as .anything that can be used to injure another person.; and establish the rationale for the .No weapon. rule, in the sense that .the .no weapon. rule is introduced to reasonably restrict the availability of weapon in facilities.. In the context of a facttype, .weapon. is a factyype role. I should then provide a .facttype role ranges over. relation to some sort of a definition of the .Merriam-Webster-weapon.. My question is what SBVR modeling element do I use to represent a .Merriam-Webster-weapon. ? In terms of compliance points, can I use the .Meaning and Representaion Vocabulary. to do that, or I need to use .Business Vocabulary. ? .Situational role. is part of the .Business Vocabulary., and not part of the MRV. How do I express the second scenario in MRV ? Can I define a .role. .Merriam-Webster-weapon. as .anything that can be used to injure a person. and use it as the destination of .facttype weapon ranges over role Merriam-Webster-weapon. ? Cheers, Nick -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Thursday, December 04, 2008 12:02 PM To: Nikolai Mansourov Cc: 'SBVR RTF' Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Date: Thu, 04 Dec 2008 13:31:00 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: "Ronald G. Ross" CC: sbvr-rtf@omg.org Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4IV2p7032090 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229020278.43462@iC1BjQQ8h8uzaVXkqgT3hQ X-Spam-Status: No Ronald G. Ross wrote: At 10:31 AM 12/4/2008, Mark H Linehan wrote: So you can have a concept called "weapon" whose definition gets updated yearly to include whatever things are considered weapons this year. I don't think I would do it like that. I believe I would simply define "weapon" as "any thing that has been used in an assault". That's the real business meaning. By the way, I am talking only about situational role as it was discussed in Clause 11. Exactly. Properly the definition would be something more like 'thing used to threaten or cause injury in a documented case of assault'. That is an object type defined as a subtype of 'thing' that has well-defined characteristics that can be evaluated at any selected point in time. If I write this formally, the characteristic involves an existential quantification over a fact-type role, and that is what makes it a "situational role". Nick wrote: Since there is some (obvious) controversy involved in the defining a 'weapon', we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. Indeed, we could also define 'weapon' as: 1) thing whose primary purpose is to cause or threaten injury to a person or animal; or 2) thing that could be used to cause or threaten injury to a person or animal. Definition 1 is not satisfied by umbrellas and bricks; it is satisfied by guns and daggers, but not by many other kinds of knife. It is an object type defined by being intended to play a specific role in a specific fact type. Definition 2 is satisfied by all umbrellas, bricks, and most scissors and kitchen cutlery. It is an object type defined by the ability to play a specific role in a specific fact type in some possible world. Ron's definition, OTOH, is importantly different from both of these, since it is defined by the existence of an actuality in which the thing played a specific role in a specific fact type. So, with respect to the same fact type ' is used to threaten or injure ', there are three role-based object types: - thing whose purpose is to play the role - thing having the ability to play the role - thing that has played the role Since SBVR is not clear as to which, if any, of these is what is meant by 'situational role', I suggest we stop discussing the properties of the undefined term 'situational role'. 'Object type' includes all role-based object types. The issue was about 'fact type role' -- the conceptualization of a "behavior" of a thing with respect to an instance of a fact type (an "atomic" state of affairs). It seems to me that some fact-type roles can be played by several object types. As Nick observed, we can always define an object type by the ability to play the role. And there is always the universal union that is 'thing'. So, "without loss of generality", we can write Necessity: Each fact type role is played by exactly one object-type. Note: when there is no defined object type that covers all the possible things that can play the role, the object type is 'thing'. This was the decision made in OWL. Why is this hard? -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: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Thu, 4 Dec 2008 13:37:53 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/04/2008 13:37:53 Nick, For your second scenario, I see two options: 1. Define an object type ..Merriam-Webster-weapon.. with an informal definition such as the one you give: ..anything that can be used to injure another person... An informal definition like this can't be automated, so will have to be applied by a human being such as the guard that you mention. 2. Define a situational role in the same way as #1 but with a slightly different definition such as ..anything that is used to injure another person.. . The main difference (as I understand it) is the additional semantic that a particular thing is a ..Merriam-Webster-weapon.. precisely by virtue of it being 'used to injure another person'. #2 is probably what you want in this case. The division between clause 8 and clause 11 is somewhat arbitrary and perhaps "situational role" could be moved to clause 8. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Nikolai Mansourov" "Nikolai Mansourov" 12/04/2008 12:46 PM To , "'SBVR RTF'" , Mark H Linehan/Watson/IBM@IBMUS cc Subject RE: SBVR Issue: can a role range over multiple object types Hi John, Your point is well taken. Actually, I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive). Let..s say in my report I want to capture both definitions of a ..weapon.. (both scenarios) and provide some connection between them. I want to define an object type ..weapon-that-can-be-identified.. as an ..object type.. as a list of ..firearm, knife, umbrella, nailclipper, bottled water..; provide an element of guidance that ..it is obligatory that the list of weapon-that-can-be-identified shall be reviewed at least annually..; define the rule that ..No weapon may be brought into a GH Facility.. in the sense that ..it is prohibited to bring a weapon-that-can-be-identified into a GH facility.. and also define a ..Merriam-Webster-weapon.. in the Merriam-Webster sense as ..anything that can be used to injure another person..; and establish the rationale for the ..No weapon.. rule, in the sense that ..the ..no weapon. rule is introduced to reasonably restrict the availability of weapon in facilities.. In the context of a facttype, ..weapon.. is a factyype role. I should then provide a ..facttype role ranges over.. relation to some sort of a definition of the ..Merriam-Webster-weapon... My question is what SBVR modeling element do I use to represent a ..Merriam-Webster-weapon. ? In terms of compliance points, can I use the ..Meaning and Representaion Vocabulary. to do that, or I need to use ..Business Vocabulary. ? ..Situational role.. is part of the ..Business Vocabulary., and not part of the MRV. How do I express the second scenario in MRV ? Can I define a ..role.. ..Merriam-Webster-weapon.. as ..anything that can be used to injure a person.. and use it as the destination of ..facttype weapon ranges over role Merriam-Webster-weapon. ? Cheers, Nick -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Thursday, December 04, 2008 12:02 PM To: Nikolai Mansourov Cc: 'SBVR RTF' Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict ..role ranges over an object type.. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a ..weapon.. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a ..weapon.., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use ..concept specialises concept.. and ..concept is coextensive with concept... The secondary mechanism is to use multiple object types in ..role ranges over object type... It is ..secondary.. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility ­ where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com pic230101.gif Date: Thu, 04 Dec 2008 13:51:51 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Nikolai Mansourov CC: "'Ronald G. Ross'" , "'keri'" , "'Mark H Linehan'" , "'SBVR RTF'" Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4IpreA002460 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229021518.95488@IiwVGHH2RRKOPCZzWefxeQ X-Spam-Status: No Nikolai Mansourov wrote: It is my understanding that the distinction between a role (and a fact type role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. This is correct. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use 'concept specialises concept' and 'concept is coextensive with concept'. The secondary mechanism is to use multiple object types in 'role ranges over object type'. It is 'secondary' in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. But the problem is exactly one of "mechanism" at the implementation level. Restricting a role to one object type often goes hand in hand with requiring every object type to have a uniform reference scheme. A model may have two fact types that do exactly the same thing for different object types (classes), because the mechanism for identifying individuals in the target implementation is based on the reference scheme, and the two classes have different reference schemes. You can't make one SQL table that works for both classes. And the uniform reference scheme rule prevents modeling the union of the two classes as an object type. SBVR is agnostic about this. It is intended to model the problem space, not the solution design. But my experience is that you can lead some object and database horses to semantic waters, but you can't make them drink. -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." X-Authority-Analysis: v=1.0 c=1 a=Gp156JHarEkA:10 a=d_nv_tyJmmkA:10 a=VnNF1IyMAAAA:8 a=_jlfX73GAAAA:8 a=hxdYrZn3AAAA:8 a=GUhdHYJAAAAA:8 a=Dnh7OmNi2miBT-mXApwA:9 a=m4Q0c4cPwAk0cIm6k3kA:7 a=njVsGlR-XIMxhH3vd6-6n7-h-tMA:4 a=gi0PWCVxevcA:10 a=frGiPHrGPy0A:10 a=s34t66kMxTcA:10 a=SlefUKKd6nw5srsM:21 a=MinmuUdlRT2c0h5-:21 a=U8x8o6RP0KXW_d6tCTkA:9 a=TmnFLgYkY5PRELYu7CUA:7 a=KXxoMbcFWy4chosjmq4NHhUlkIwA:4 a=Sz-0p1zU2dQA:10 a=goLX42PLkwr6n1NL:21 a=Ys1CPqPFQRqQy9ZP:21 a=34s-83_RF14fRxIKVNgA:9 a=uYYJkxNcDF-7FbcEf9WgbFFFcQUA:4 a=CxA2Utj4LuEA:10 a=1Vq_FK4TplAA:10 a=I2jQ6tLuKlH2JyhFh7EA:9 a=lQgEDWtra2I10bwY0HMA:9 a=aP0L-lBtr_BARAvkHikNaHoowDYA:4 a=fjePP5sT1724HupjafkA:9 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 04 Dec 2008 09:10:30 -1000 Subject: Re: SBVR Issue: can a role range over multiple object types From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWQ/ksN3z+ksI3Ed2Z/QARJM+Cgg== I see that my original ("simple to grasp") example has become a distraction. (NB: This did come from an actual sign, with a very specific meaning to a single community, so postulating what it could/should/would mean in some abstract/hypothetical/dictionary context has become not helpful.) Let's try a more familiar example to see if the conversation can be directed back on the business purpose of 'role' (of the non-fact-type-role kind). Take "customer", which would be specified as 'role'. There are no direct instances of 'customer' -- its instances 'come from' other concepts, namely (typically) from 'person' and 'organization'. A person (or organization) "steps into" the role of 'customer' under certain conditions (SBVR would say "situation"). It was my understanding that this "ranges over" fact type was the way that I would specify, for the concept of 'customer', that its 'sources' (where its instances can ultimately come from) are 'person' and 'organization'. If I have this role sense of 'customer' and I cannot specify this via 'customer' ranges over 'person' and 'organization', then how would 'customer' as a role be understood/specified? ~ Keri On 12/4/08 8:37 AM, "Mark H Linehan" wrote: Nick, For your second scenario, I see two options: 1. Define an object type .Merriam-Webster-weapon. with an informal definition such as the one you give: .anything that can be used to injure another person.. An informal definition like this can't be automated, so will have to be applied by a human being such as the guard that you mention. 2. Define a situational role in the same way as #1 but with a slightly different definition such as .anything that is used to injure another person. . The main difference (as I understand it) is the additional semantic that a particular thing is a .Merriam-Webster-weapon. precisely by virtue of it being 'used to injure another person'. #2 is probably what you want in this case. The division between clause 8 and clause 11 is somewhat arbitrary and perhaps "situational role" could be moved to clause 8. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Nikolai Mansourov" "Nikolai Mansourov" 12/04/2008 12:46 PM To , "'SBVR RTF'" , Mark H Linehan/Watson/IBM@IBMUS cc Subject RE: SBVR Issue: can a role range over multiple object types Hi John, Your point is well taken. Actually, I do agree with Mark that in reality in the particular context of a statement "No weapon may be brought into a GH Facility" only the first scenario is feasible (otherwise this rule cannot be enforced in a meaningful way when people are entering the building, it can only be enforced after the fact when they used something to injure another person; defining a weapon as anything that can be used to injure a person is too restrictive). Let.s say in my report I want to capture both definitions of a .weapon. (both scenarios) and provide some connection between them. I want to define an object type .weapon-that-can-be-identified. as an .object type. as a list of .firearm, knife, umbrella, nailclipper, bottled water.; provide an element of guidance that .it is obligatory that the list of weapon-that-can-be-identified shall be reviewed at least annually.; define the rule that .No weapon may be brought into a GH Facility. in the sense that .it is prohibited to bring a weapon-that-can-be-identified into a GH facility. and also define a .Merriam-Webster-weapon. in the Merriam-Webster sense as .anything that can be used to injure another person.; and establish the rationale for the .No weapon. rule, in the sense that .the .no weapon. rule is introduced to reasonably restrict the availability of weapon in facilities.. In the context of a facttype, .weapon. is a factyype role. I should then provide a .facttype role ranges over. relation to some sort of a definition of the .Merriam-Webster-weapon.. My question is what SBVR modeling element do I use to represent a .Merriam-Webster-weapon. ? In terms of compliance points, can I use the .Meaning and Representaion Vocabulary. to do that, or I need to use .Business Vocabulary. ? .Situational role. is part of the .Business Vocabulary., and not part of the MRV. How do I express the second scenario in MRV ? Can I define a .role. .Merriam-Webster-weapon. as .anything that can be used to injure a person. and use it as the destination of .facttype weapon ranges over role Merriam-Webster-weapon. ? Cheers, Nick -------------------------------------------------------------------------------- From: John Hall [mailto:john.hall@modelsys.com] Sent: Thursday, December 04, 2008 12:02 PM To: Nikolai Mansourov Cc: 'SBVR RTF' Subject: Re: SBVR Issue: can a role range over multiple object types Hi Nick, It seems to me that there are two scenarios: One is where there is a defined set of types of thing that can fill the situational role. So, if only guns knives and umbrellas are considered as weapons, we can have an extensional definition "gun or knife or umbrella". Then it's OK to take a baseball bat or a chainsaw into the premises (at least under the rule about taking weapons in). The other is where there is a catch-all at the end of the list ".. or anything else we might consider to be dangerous". Then the definition of weapon is "Anything we might consider to be dangerous", and the specifically-named items are just examples. Regards, John Nikolai Mansourov wrote: Hello all, The reason I agrue to restrict .role ranges over an object type. is that I am a strong proponent of having a single mechanism to achieve a given goal when it comes to specifications. One thing that our example demonstrates, is that the concept of a .weapon. may have a larger scope than a particular role in a particular fact type. Since there is some (obvious) controversy involved in the defining a .weapon., we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. It is my understanding that the distinction between a role (and a facttype role) and an object type is that of a scope. More specifically, the scope of a facttype role is restricted to a single facttype. On the other hand, the scope of an object type is an entire conceptual schema. Of course, the issue at hand is only about the technical complexity of the spec: do we allow TWO mechanisms to represent subclasses in the extent of some concept or just ONE. In my opinion, the primary mechanism is to use .concept specialises concept. and .concept is coextensive with concept.. The secondary mechanism is to use multiple object types in .role ranges over object type.. It is .secondary. in my opinion, because of the scope restriction. There is a blip on my radar, when I observe the duplication of mechanisms in a specification, as this undermines the power of the specification to provide guidance, as well as complicates the implementation. Best regards, Nick -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com ] Sent: Wednesday, December 03, 2008 4:57 PM To: keri; Mark H Linehan; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types At 02:53 PM 12/3/2008, keri wrote: FWIW, the early business sense was to mean that things from multiple 'object types' could step in to fill a given role. One of the examples discussed was that of the Group Health rule that prohibits a 'weapon' from being brought into a GH Facility where the things that can play the role of 'weapon' (in their view) are: gun, knife, and umbrella. brick, key, baseball bat, fire extinguisher, vehicle, (non-guard) dog ... things not likely to be naturally considered all categories of a broader concept ... until they are put to use (spontaneously) as a weapon. ~ Keri On 12/3/08 9:51 AM, "Mark H Linehan" > wrote: The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Date: Thu, 04 Dec 2008 14:34:43 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Mark H Linehan CC: sbvr-rtf@omg.org Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4JYj7F007838 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229024094.69477@Ul31lRnejyNeiTBSHrvabg X-Spam-Status: No Mark H Linehan wrote: For your second scenario, I see two options: 1. Define an object type ..Merriam-Webster-weapon.. with an informal definition such as the one you give: ..anything that can be used to injure another person... An informal definition like this can't be automated, so will have to be applied by a human being such as the guard that you mention. 2. Define a situational role in the same way as #1 but with a slightly different definition such as ..anything that is used to injure another person.. . The main difference (as I understand it) is the additional semantic that a particular thing is a ..Merriam-Webster-weapon.. precisely by virtue of it being 'used to injure another person'. These are two of the suggestions in my email. They are both object-types. #2 is probably what you want in this case. #2 is not clear. Does it mean 'thing whose purpose is to injure another person'? Or 'thing that is being (or has been) used to injure another person'. The first would include guns but not umbrellas, and might miss Sneed's sword-cane. The second would only include guns that have actually been fired at persons. The point is that each variant of 'used to injure' -- purpose is to injure, can be used to injure, has been used to injure -- is a different semantic, and the corresponding concept has a different extension. The division between clause 8 and clause 11 is somewhat arbitrary and perhaps "situational role" could be moved to clause 8. I strongly disagree. 'Situational role' is not well-defined. I would prefer that it be moved to the wastebasket. It apparently means "any object type whose delimiting characteristics are somehow related to one or more fact types". And that is a synonym for object type. I think 'situational role' is a temporal concept. It has to do with currently satisfying characteristics that may not be satisfied at a later time. But SBVR doesn't have temporal concepts. What it has is facts versus necessities. So we would have to define situational role as an object type based on playing a role in an actuality that is not a necessity. And that is not really what we want, because businesses also have persistent actualities that are not invariants in all possible worlds. And one probably does not want to consider persistent roles as situational. That is, 'bank manager' is a situational role, but 'U.S. citizen' may not be considered to be. I just don't see an advantage to classifying object types as situational roles. What useful properties does a 'situational role' have? -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." Date: Thu, 04 Dec 2008 14:36:10 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: sbvr-rtf@omg.org Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4JaChL008015 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229024182.10839@IFP97akEc1hz45MqCs1ILw X-Spam-Status: No This seems to have vanished into the OMG bit bucket. I sent this over an hour ago. Ronald G. Ross wrote: At 10:31 AM 12/4/2008, Mark H Linehan wrote: So you can have a concept called "weapon" whose definition gets updated yearly to include whatever things are considered weapons this year. I don't think I would do it like that. I believe I would simply define "weapon" as "any thing that has been used in an assault". That's the real business meaning. By the way, I am talking only about situational role as it was discussed in Clause 11. Exactly. Properly the definition would be something more like 'thing used to threaten or cause injury in a documented case of assault'. That is an object type defined as a subtype of 'thing' that has well-defined characteristics that can be evaluated at any selected point in time. If I write this formally, the characteristic involves an existential quantification over a fact-type role, and that is what makes it a "situational role". Nick wrote: Since there is some (obvious) controversy involved in the defining a 'weapon', we can as well promote it to become a concept in a larger scope. This way we anticipate that there may be more fact types in which this concept is involved. Indeed, we could also define 'weapon' as: 1) thing whose primary purpose is to cause or threaten injury to a person or animal; or 2) thing that could be used to cause or threaten injury to a person or animal. Definition 1 is not satisfied by umbrellas and bricks; it is satisfied by guns and daggers, but not by many other kinds of knife. It is an object type defined by being intended to play a specific role in a specific fact type. Definition 2 is satisfied by all umbrellas, bricks, and most scissors and kitchen cutlery. It is an object type defined by the ability to play a specific role in a specific fact type in some possible world. Ron's definition, OTOH, is importantly different from both of these, since it is defined by the existence of an actuality in which the thing played a specific role in a specific fact type. So, with respect to the same fact type ' is used to threaten or injure ', there are three role-based object types: - thing whose purpose is to play the role - thing having the ability to play the role - thing that has played the role Since SBVR is not clear as to which, if any, of these is what is meant by 'situational role', I suggest we stop discussing the properties of the undefined term 'situational role'. 'Object type' includes all role-based object types. The issue was about 'fact type role' -- the conceptualization of a "behavior" of a thing with respect to an instance of a fact type (an "atomic" state of affairs). It seems to me that some fact-type roles can be played by several object types. As Nick observed, we can always define an object type by the ability to play the role. And there is always the universal union that is 'thing'. So, "without loss of generality", we can write Necessity: Each fact type role is played by exactly one object-type. Note: when there is no defined object type that covers all the possible things that can play the role, the object type is 'thing'. This was the decision made in OWL. Why is this hard? -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." Date: Thu, 04 Dec 2008 15:04:30 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: keri CC: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4K4XjP011671 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229025878.44551@xylV+3LqBQU4WDjkjXZgkw X-Spam-Status: No It is too bad Keri's message didn't arrive before Mark's. keri wrote: > Let's try a more familiar example to see if the conversation can be directed > back on the business purpose of 'role' (of the non-fact-type-role kind). > > Take "customer", which would be specified as 'role'. There are no direct > instances of 'customer' -- its instances 'come from' other concepts, namely > (typically) from 'person' and 'organization'. A person (or organization) > "steps into" the role of 'customer' under certain conditions (SBVR would say > "situation"). There is no formal definition of 'role' here. And SBVR has no notion of 'steps into'. Keri is talking about a change of state. A world is. A later world is a different world. SBVR has no temporal concept, no concept of ordering worlds. So this concept, which relies on those notions, is out of scope in SBVR v1. But that doesn't mean we have to discard it. It just means that the formal notions its definition needs are unavailable. > It was my understanding that this "ranges over" fact type was the way that I > would specify, for the concept of 'customer', that its 'sources' (where its > instances can ultimately come from) are 'person' and 'organization'. If I > have this role sense of 'customer' and I cannot specify this via 'customer' > ranges over 'person' and 'organization', then how would 'customer' as a role > be understood/specified? I think the problem here is that 'role ranges over object type' is a common syntactic fact type, but the structural rules, *and thus the meaning*, are different for the different subtypes of 'role'. fact type role ranges over concept means that the only things that can meaningfully play the role are those denoted by concept. For any thing that is not an instance of 'concept', the fact type is meaningless. That intent is exclusive. situational role ranges over object type means that things that correspond to the object type are eligible to take on the situational role. That intent is inclusive. There may be other things that are also eligible. So we have another case of homographs. Two different fact types. Same term, different designation, different meaning. I suggest we just split them up. -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." X-Authority-Analysis: v=1.0 c=1 a=Gp156JHarEkA:10 a=d_nv_tyJmmkA:10 a=ep5XYqAzd9fAFt1CcmoA:9 a=ZhaWGcoWtcTn-QwE44i_IQs9V6QA:4 a=LY0hPdMaydYA:10 a=n0MxijT0Om7qKIEoh4cA:9 a=yQZT2iTUp546ooU0db8A:7 a=b_sfCrpo_DH9RO2NegxDYW7tv24A:4 a=Sz-0p1zU2dQA:10 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 04 Dec 2008 10:27:25 -1000 Subject: Re: SBVR Issue: can a role range over multiple object types From: keri To: Ed Barkmeyer , SBVR RTF Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWTrft9lPIs8JBEd2gpAARJM+Cgg== On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > There is no formal definition of 'role' here. And SBVR has no notion of > 'steps into'. Keri is talking about a change of state. A world is. A > later world is a different world. SBVR has no temporal concept, no > concept of ordering worlds. So this concept, which relies on those > notions, is out of scope in SBVR v1. But that doesn't mean we have to > discard it. It just means that the formal notions its definition needs > are unavailable. Let me try again. I agree that the "steps into" wording is not SBVR-speak. But the notion I was talking about is not state change. Perhaps if we can get on the same page about the basics of what this non-fact-type-role is about then we can build on that and sort out how 'ranges over' fits in. In Clause 11 we attempted make a basic distinction between 'fundamental' and 'situational' -- concepts where it's part of the 'essence' of a thing to be one of those vs. concepts where its things are perceived to be instances situationally. Kinda hard to say this formally ... "steps into the role" ("plays the role") just seems easier to grasp. This isn't something that the SBVRites made up out of whole cloth. E.g., Sowa talks about 'pet' (role) vs. 'animal' (fundamental). Sorry -- I don't have my Sowa book handy to recall his particular terminology. In any case, Fluffy does not undergo a state change when I perceive her as a pet because of her situation. And whether or not Fluffy is playing that role she is fundamentally . as part of her essence . always an animal (cat). Keri X-Authority-Analysis: v=1.0 c=1 a=Gp156JHarEkA:10 a=d_nv_tyJmmkA:10 a=PxtzMiiDS0DkXjlZmNQA:9 a=91cgCS2xUrDvTscXcNIA:7 a=TPGE6NlNRW-fAnz23BMJIAjIUpUA:4 a=LY0hPdMaydYA:10 a=jG8vuTxhxM4DxdgpNLsA:9 a=zDa5MHHbMlXQ5UmNf2QA:7 a=4eTuQPj65PSX0_bQtZDhkFyYEL0A:4 a=Sz-0p1zU2dQA:10 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 04 Dec 2008 10:37:28 -1000 Subject: Re: SBVR Issue: can a role range over multiple object types From: keri To: Ed Barkmeyer CC: SBVR RTF Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWUB9XXajUGMJDEd2gpAARJM+Cgg== On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > I think the problem here is that 'role ranges over object type' is a > common syntactic fact type, but the structural rules, *and thus the > meaning*, are different for the different subtypes of 'role'. > > fact type role ranges over concept > means that the only things that can meaningfully play the role are > those denoted by concept. For any thing that is not an instance of > 'concept', the fact type is meaningless. That intent is exclusive. > > situational role ranges over object type > means that things that correspond to the object type are eligible to > take on the situational role. That intent is inclusive. There may be > other things that are also eligible. Interesting... not sure I grasp what's going on in the distinction you are making in the second 'ranges over'. Why could I not write the second in a way more parallel with the first, as follows: > situational role ranges over object type > means that the only things that can meaningfully play the role are > those denoted by concept. Any thing that is not an instance of > 'concept' cannot be a meaningful role-player in the situation. That intent is exclusive. Keri From: "Nikolai Mansourov" To: , "'Mark H Linehan'" Cc: Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 16:06:20 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWR4AuG7OIoO7iTtGcycscEJSavwACxOmA X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hi Ed, Thanks for the explanation, and further examples. You brought more subtlety into the original list of 'is listed as a weapon' and 'was actually used to injure'. I like 'whose purpose is to injure', vs 'could be used to injure'. So, what you are saying is that a 'situational role' element is SBVR is a kind of an 'abstract class' (in the sense of EMF or Java): we can use it and 'talk about' it, but we cannot instantiate it. Is this the same for the element 'role' ? Do you see an 'object type' and a 'facttyperole' as the only concrete elements in this realm ? In my experience of providing SBVR SDK this is exactly the approach that we took. I have made quite a few of the SBVR model elements an abstract class in EMF. It also seems to be consistent with the usage in the examples from the specification (I need to run a text search to double check this claim). It is important to have these elements in the specification as part of the SBVR vocabulary for the purpose of 'talking about' elements of a business vocabulary, but they don't seem to be part of a business vocabulary in the sense of instantiation (i.e. being used in the SBVR XMI representation of that vocabulary as one of the tags). Would you agree ? Cheers, Nick -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Thursday, December 04, 2008 2:35 PM To: Mark H Linehan Cc: sbvr-rtf@omg.org Subject: Re: SBVR Issue: can a role range over multiple object types Mark H Linehan wrote: > For your second scenario, I see two options: > > 1. Define an object type 'Merriam-Webster-weapon' with an informal > definition such as the one you give: 'anything that can be used to injure > another person'. An informal definition like this can't be automated, so > will have to be applied by a human being such as the guard that you > mention. > > 2. Define a situational role in the same way as #1 but with a slightly > different definition such as 'anything that is used to injure another > person' . The main difference (as I understand it) is the additional > semantic that a particular thing is a 'Merriam-Webster-weapon' precisely by > virtue of it being 'used to injure another person'. These are two of the suggestions in my email. They are both object-types. > #2 is probably what you want in this case. #2 is not clear. Does it mean 'thing whose purpose is to injure another person'? Or 'thing that is being (or has been) used to injure another person'. The first would include guns but not umbrellas, and might miss Sneed's sword-cane. The second would only include guns that have actually been fired at persons. The point is that each variant of 'used to injure' -- purpose is to injure, can be used to injure, has been used to injure -- is a different semantic, and the corresponding concept has a different extension. > The division between clause 8 and clause 11 is somewhat arbitrary and > perhaps "situational role" could be moved to clause 8. I strongly disagree. 'Situational role' is not well-defined. I would prefer that it be moved to the wastebasket. It apparently means "any object type whose delimiting characteristics are somehow related to one or more fact types". And that is a synonym for object type. I think 'situational role' is a temporal concept. It has to do with currently satisfying characteristics that may not be satisfied at a later time. But SBVR doesn't have temporal concepts. What it has is facts versus necessities. So we would have to define situational role as an object type based on playing a role in an actuality that is not a necessity. And that is not really what we want, because businesses also have persistent actualities that are not invariants in all possible worlds. And one probably does not want to consider persistent roles as situational. That is, 'bank manager' is a situational role, but 'U.S. citizen' may not be considered to be. I just don't see an advantage to classifying object types as situational roles. What useful properties does a 'situational role' have? -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: "Nikolai Mansourov" To: "'keri'" , "'Ed Barkmeyer'" Cc: "'SBVR RTF'" Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 16:16:16 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWUB9XXajUGMJDEd2gpAARJM+CggABCogQ X-Authenticated: nickmansurov - ottawa-hs-64-26-169-119.s-ip.magma.ca (MERGANSER) [64.26.169.119] Hi Keri, What is .fact type role ranges over concept. vs. .situational role ranges over object type. ? I was under the impression that SBVR only has .role ranges over object type.. I do believe that it could be upgraded to .role ranges over concept.. This becomes irrelevant (from the implementation perspective), if the advise it to view .concept., .noun concept., .role. and .situational role. as some sort of abstract classes that do not find their way in the instances of an SBVR XMI document for representing a given vocabulary; and .object type. and .facttype role. as some sort of concrete classes that do. Cheers, Nick -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: Thursday, December 04, 2008 3:37 PM To: Ed Barkmeyer Cc: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > I think the problem here is that 'role ranges over object type' is a > common syntactic fact type, but the structural rules, *and thus the > meaning*, are different for the different subtypes of 'role'. > > fact type role ranges over concept > means that the only things that can meaningfully play the role are > those denoted by concept. For any thing that is not an instance of > 'concept', the fact type is meaningless. That intent is exclusive. > > situational role ranges over object type > means that things that correspond to the object type are eligible to > take on the situational role. That intent is inclusive. There may be > other things that are also eligible. Interesting... not sure I grasp what's going on in the distinction you are making in the second 'ranges over'. Why could I not write the second in a way more parallel with the first, as follows: > situational role ranges over object type > means that the only things that can meaningfully play the role are > those denoted by concept. Any thing that is not an instance of > 'concept' cannot be a meaningful role-player in the situation. That intent is exclusive. Keri Date: Thu, 04 Dec 2008 16:22:46 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4LMmeD021286 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229030573.19562@yQ7c6BsN4zlcnXA3nh14LA X-Spam-Status: No I wrote: > situational role ranges over object type > means that things that correspond to the object type are eligible to > take on the situational role. That intent is inclusive. There may be > other things that are also eligible. I should have mentioned: The inclusive intent is only useful if there is a presumed prohibition: nothing can be a customer except what we include. The SBVR default is permission: "Any thing can be a customer, unless there is some rule that restricts it." So saying that 'customer ranges over person' is actually just stating an advice, or an example. Further, how do we define 'customer'? It suggests that we can define customer without mentioning persons or organizations. If the definition of customer is: person or organization that buys a product or service Why would we need the fact type 'situational role ranges over object type' at all? The definition of the situational role relates it directly to the object types that can play the role. (We need this for fact type role, because fact type roles don't have definitions. Only the fact type does. The range of the fact type role is part of the formal definition of the fact type. And that, BTW, is how the circularity problem is avoided -- you can't define either without the other, so you define them together.) It does seem that the characteristic thing buys a product or service is the formulation of some 'situation'. How do I distinguish that from a characteristic that does not formulate a 'situation'? What is the difference? I'm willing to let this go, but I have yet to see a clear distinction in properties between 'object type' and 'situational role'. Whatever those properties are, they must involve concepts that SBVR doesn't have. -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: State <-- SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 13:42:15 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State <-- SBVR Issue: can a role range over multiple object types Thread-Index: AclWTrft9lPIs8JBEd2gpAARJM+CggACUjlQ Priority: Non-Urgent From: "Paul Vincent" To: "keri" , "Ed Barkmeyer" , "SBVR RTF" X-OriginalArrivalTime: 04 Dec 2008 21:42:19.0512 (UTC) FILETIME=[2EDD8F80:01C95659] Hi Keri . that.s interesting. Might it be your .perception. that changes state from understanding Fluffy (.s role) as a pet, from just some other annoying animal (role). ? Isn.t .state. in SBVR is just considered another fact type? [Sorry to digress. but at Tibco we use state modeling in our CEP product to help model situations like .changeable roles. . an IT perspective, of course]. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 04 December 2008 20:27 To: Ed Barkmeyer; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > There is no formal definition of 'role' here. And SBVR has no notion of > 'steps into'. Keri is talking about a change of state. A world is. A > later world is a different world. SBVR has no temporal concept, no > concept of ordering worlds. So this concept, which relies on those > notions, is out of scope in SBVR v1. But that doesn't mean we have to > discard it. It just means that the formal notions its definition needs > are unavailable. Let me try again. I agree that the "steps into" wording is not SBVR-speak. But the notion I was talking about is not state change. Perhaps if we can get on the same page about the basics of what this non-fact-type-role is about then we can build on that and sort out how 'ranges over' fits in. In Clause 11 we attempted make a basic distinction between 'fundamental' and 'situational' -- concepts where it's part of the 'essence' of a thing to be one of those vs. concepts where its things are perceived to be instances situationally. Kinda hard to say this formally ... "steps into the role" ("plays the role") just seems easier to grasp. This isn't something that the SBVRites made up out of whole cloth. E.g., Sowa talks about 'pet' (role) vs. 'animal' (fundamental). Sorry -- I don't have my Sowa book handy to recall his particular terminology. In any case, Fluffy does not undergo a state change when I perceive her as a pet because of her situation. And whether or not Fluffy is playing that role she is fundamentally . as part of her essence . always an animal (cat). Keri Date: Thu, 04 Dec 2008 18:05:40 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: keri CC: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4N5gxZ032596 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229036744.11442@/C54833QDRqMl6hAddMsbQ X-Spam-Status: No I wrote: There is no formal definition of 'role' here. And SBVR has no notion of 'steps into'. Keri is talking about a change of state. A world is. A later world is a different world. SBVR has no temporal concept, no concept of ordering worlds. So this concept, which relies on those notions, is out of scope in SBVR v1. But that doesn't mean we have to discard it. It just means that the formal notions its definition needs are unavailable. Keri wrote: Let me try again. I agree that the "steps into" wording is not SBVR-speak. But the notion I was talking about is not state change. Perhaps if we can get on the same page about the basics of what this non-fact-type-role is about then we can build on that and sort out how 'ranges over' fits in. In Clause 11 we attempted make a basic distinction between 'fundamental' and 'situational' -- concepts where it's part of the 'essence' of a thing to be one of those vs. concepts where its things are perceived to be instances situationally. Kinda hard to say this formally ... "steps into the role" ("plays the role") just seems easier to grasp. This isn't something that the SBVRites made up out of whole cloth. E.g., Sowa talks about 'pet' (role) vs. 'animal' (fundamental). Sorry -- I don't have my Sowa book handy to recall his particular terminology. All of this is well-known metaphysical stuff. The distinction is between essential/intrinsic properties and accidental/extrinsic properties. But when you try to formalize this fireside metaphysics, you have to decide what logical model (and epistemological model) you want to start with. The view that Sowa takes is that "Toto is a dog" is an invariant (of sorts), and therefore fundamental. More accurately, 'Toto' is not a thing in the universe of discourse if it is not a dog. That is, not every world must contain Toto, but in every world that contains Toto, Toto is a dog. But "Toto is a pet" is only true in this world, at this time. There are other possible worlds in which Toto exists and is not a pet. And if we adopt that distinction, it is clear what we mean. SBVR makes the distinction between fact and necessity, so it can phrase the concept as follows: invariant characteristic: characteristic that is satisfied by a given thing in a possible world only if it is satisfied by that thing in all possible worlds that contain the given thing. situational role: object type that has at least one essential characteristic that is not an invariant characteristic. (I would be happy with this, but I will be very interested in Terry's position. There is also a big philosophical problem in the relationship between possible worlds and the universe of discourse. What is the nature of an individual?) The remaining question is: Is that really what we mean by 'situational role'? I suspect it will cause unexpected object types to be classified as situational roles. But I can't offhand think of any. We create 'situational roles' specifically to abstract the participation in fact types away from the individual states of affairs, so that we can talk about the class of participants as an object type. A "pet" is always "someone's pet", but for some purposes, we don't care whose. A "bank manager" is a manager of some bank, but we don't care which one. But some roles are rollups of several fact type roles into a kind of aggregate role with respect to some amorphous business notion, like a position defined by its duties. (But a position is not a situational role -- it is actually a model of a situational role that is seen as a business entity in its own right.) What we are doing here is casting about for a formal characterization of 'situational role', so that we can talk with some certainty about what properties it has. -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." Date: Thu, 04 Dec 2008 18:11:36 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: keri CC: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4NBcfp000631 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229037101.29981@FpCLydnPUNTdDNIwof8IlA X-Spam-Status: No keri wrote: On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: I think the problem here is that 'role ranges over object type' is a common syntactic fact type, but the structural rules, *and thus the meaning*, are different for the different subtypes of 'role'. fact type role ranges over concept means that the only things that can meaningfully play the role are those denoted by concept. For any thing that is not an instance of 'concept', the fact type is meaningless. That intent is exclusive. situational role ranges over object type means that things that correspond to the object type are eligible to take on the situational role. That intent is inclusive. There may be other things that are also eligible. Interesting... not sure I grasp what's going on in the distinction you are making in the second 'ranges over'. Why could I not write the second in a way more parallel with the first, as follows: situational role ranges over object type means that the only things that can meaningfully play the role are those denoted by concept. Any thing that is not an instance of 'concept' cannot be a meaningful role-player in the situation. That intent is exclusive. You can, but then you cannot write both: 'customer ranges over person' and 'customer ranges over organization' The first statement contradicts the second, because you made the intent exclusive. The first statement says that it is not meaningful for any thing that is not a person to be a customer. Unless every organization is a person, the second statement must be false. You would have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' And that is precisely the issue. Do you want to have to do that? -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: "Nikolai Mansourov" To: , "'keri'" Cc: "'SBVR RTF'" Subject: RE: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 18:32:26 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AclWZb47ln6db+erTjezCtyluW/IaAAAQyEg X-Authenticated: nickmansurov - cpe000fb0a4c9b2-cm0011ae8cd9a2.cpe.net.cable.rogers.com (MERGANSER) [99.224.70.220] These are exactly the choices we have: 1. You *always* have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' This is achieved by multiplicity of 'ranges over object type' being always 1 2. you can either write the above OR you can write: 'customer ranges over person or organization' you introduced a second mechanism for an on-the-fly definition of an 'anonymous' concept 'xxx is defined as 'person or organization'. This is allowed by multiplicity of 'ranges over object type' being 1 or many. My personal preference is to have an orthogonal set of mechanisms in a language. This makes a language easy to explain to the tool vendors and to the users. This in most cases leads to more disciplined products created with the use of the languages. For example, in the first case you may be encouraged to add comments, rationale, examples and notes to the concept 'legal entity'. On the other hand, in the second case the anonymous entity is a 'second class citizen'. To me this is a bit of a metaphysical challenge. I can see how other people can favour #2 as providing more power to the users of the language. Well, maybe in this case the tool vendors can (internally) reduce case #2 to #1 by introducing this anonymous concept behind the scenes, and still be happy. Just a thought. Cheers, Nick -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Thursday, December 04, 2008 6:12 PM To: keri Cc: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types keri wrote: > On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > >> I think the problem here is that 'role ranges over object type' is a >> common syntactic fact type, but the structural rules, *and thus the >> meaning*, are different for the different subtypes of 'role'. >> >> fact type role ranges over concept >> means that the only things that can meaningfully play the role are >> those denoted by concept. For any thing that is not an instance of >> 'concept', the fact type is meaningless. That intent is exclusive. >> >> situational role ranges over object type >> means that things that correspond to the object type are eligible to >> take on the situational role. That intent is inclusive. There may be >> other things that are also eligible. > > > Interesting... not sure I grasp what's going on in the distinction you are > making in the second 'ranges over'. > > Why could I not write the second in a way more parallel with the first, as > follows: > >>>> situational role ranges over object type >>>> means that the only things that can meaningfully play the role are >>>> those denoted by concept. Any thing that is not an instance of >>>> 'concept' cannot be a meaningful role-player in the situation. That intent >>> is exclusive. You can, but then you cannot write both: 'customer ranges over person' and 'customer ranges over organization' The first statement contradicts the second, because you made the intent exclusive. The first statement says that it is not meaningful for any thing that is not a person to be a customer. Unless every organization is a person, the second statement must be false. You would have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' And that is precisely the issue. Do you want to have to do that? -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: SBVR Issue: can a role range over multiple object types Date: Thu, 4 Dec 2008 16:32:39 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWZPiMp6Szox/bTB6B2I+QyNLrqgAAgrDQ From: "Terry Halpin" To: , "keri" Cc: "SBVR RTF" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id mB4NW0AH027126 Ed said: <> Ed, it's unclear to me how an essential property is not invariant. How do you define "essential"? It seems to me that the main need is to distinguish between rigid types (instances of a rigid type must remain in that type for their lifetime, e.g. Person) and what I call "role types" (instances may enter or leave a role type during their lifetime, e.g. Customer). I use "role type" liberally to embrace not just ontological roles but also phases (e.g. Child, Adult) etc. From memory, I think SBVR's "situational role" corresponds at least roughly to what I call a role type. Cheers Terry Date: Thu, 04 Dec 2008 18:56:47 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Nikolai Mansourov CC: "'SBVR RTF'" Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB4NuoPO004740 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229039812.01574@Nmjx7wHZ3wkWqMCqodHI4g X-Spam-Status: No Nikolai Mansourov wrote: What is 'fact type role ranges over concept' vs. 'situational role ranges over object type' ? I was under the impression that SBVR only has 'role ranges over object type'. I do believe that it could be upgraded to 'role ranges over concept'. That's my fault. And I'm pretty sure we don't need to do that. From Keri's contributions, the intent for situational role is clearly: role ranges over object type Now SBVR itself has fact types like concept1 specializes concept2 in which the fact type role 'concept1' ranges over 'concept' and can be played by a fact type. So here we have the ultimate use/mention mess. The thing 'concept' is an instance of 'object type' -- it characterizes multiple things by their common properties. In particular, it characterizes things that - are meanings - are not complete thoughts (propositions) So the role (instance) 'concept1' ranges over the object type (instance) 'concept'. So fact type role ranges over object type is the most accurate fact type. My point in that email, however, was that we can only generalize to 'role ranges over object type' if it has the same (exclusive) meaning for both subtypes of 'role'. -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." Date: Thu, 04 Dec 2008 19:24:44 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Terry Halpin CC: SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB50Ols8007318 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229041490.90133@q9040aN/jCG5qDF4CWyCQg X-Spam-Status: No Terry Halpin wrote: <> Ed, it's unclear to me how an essential property is not invariant. How do you define "essential"? It seems to me that the main need is to distinguish between rigid types (instances of a rigid type must remain in that type for their lifetime, Yes. My error. The common term in logic is 'rigid', and I believe the definition above, rewritten as: rigid characteristic: characteristic that is satisfied by a thing in a possible world only if it is satisfied by that thing in all possible worlds that contain that thing. is a variation of the usual definition of "rigid", i.e.: (forall x)(If (C x) (Necessity (C x))) SBVR defines "essential characteristics" to mean "necessary and sufficient characteristics", following ISO 1087-1, I think. But in this sense, C is a necessary characteristic of T means only: (Necessity (forall x)(if (T x) (C x))) It says nothing about the truth of (T x) in any other world. e.g. Person) and what I call "role types" (instances may enter or leave a role type during their lifetime, e.g. Customer). I use "role type" liberally to embrace not just ontological roles but also phases (e.g. Child, Adult) etc. From memory, I think SBVR's "situational role" corresponds at least roughly to what I call a role type. So rigid type: object type whose essential characteristics are all rigid. role type: object type that has at least one necessary characteristic that is not rigid. Is this correct? And the observation about role types including phases is exactly the kind of thing I meant when I said to Keri that you might thus classify some object types as situational roles that you didn't expect. Thanks for the correction in terminology. (While Keri and others may find this formal approach a lot less intuitive, we can fix that with notes and examples. The point is that we can produce a clear definition of 'role type', aka 'situational role', as distinct from a Volksdefinition.) -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@omg.org" Date: Thu, 4 Dec 2008 21:34:40 -0800 Subject: RE: SBVR issue 13135 -- RANGES OVER Thread-Topic: SBVR issue 13135 -- RANGES OVER Thread-Index: AclVgt/gc/XXrnt0SKCLCn/COUQ18QBBPD0Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US The fact type .role ranges over object type. is formally defined by SBVR in terms of incorporated characteristics (the intensions) of the role and object type. You can go ahead and add a necessity statement, .Each role ranges over exactly one object type., if you can logically conclude the truth of that statement from the definition. There seems to be two use cases for SBVR here. One is for people who think of a concept system as something designed. Good design practice might limit the specification of a fact type role to range over a single object type. The other use case is for people who think of a concept system as something discovered. The first use case is more like programming and is suited to being limited by edict of the metadesigners, and the notations used can be restricted by such limits. But the discovery case deals with concept systems and vocabularies that are already in use. It is not suited to being limited by edict. And it must support gradual acquisition of information . it is not reasonable to assume that an entire concept system is assimilated all at once. Consider the work of someone learning and documenting the vocabulary of some community. They find a fact type reading .man is married to woman. and rightly conclude that the fact type.s .woman. role ranges over the object type .woman.. They discover an object type .wife. defined as .woman who is married to a man.. They find another fact type reading .man has wife. and rightly conclude that the fact type.s .wife. role ranges over the object type .wife.. But the two fact type readings are for the same fact type. The .woman. fact type role and the .wife. fact type role are the same fact type role. This is not a problem. The object type .wife. incorporates no characteristics that are not already incorporated into the .woman. role of .man is married to woman.. This is obvious from the definition of the object type .wife.. Discovery that .man has wife. represents the same fact type as .man is married to woman. reveals that the .wife./.woman. role ranges over the two object types .wife. and .woman.. A tool might choose to show only the most specific or only the most general, but that is a tool thing. The fact that the role ranges over one does not change the fact that it also ranges over the other. Discovery of the readings and the ranged over object types can happen in any order. It.s nice that we can add knowledge as it is discovered without contradicting what is already known. The open world assumption works well in discovery mode. SBVR handles the discovery use case just fine, and since I tend to find myself in the discovery case, I.m glad it does. But perhaps I have too little sympathy for people working the other use case. I am not saying that a fact type .person is married to person. is the same as the fact type .man is married to woman.. They are distinct fact types. They and their roles incorporate different characteristics. As for Mark.s .impact. (a) and (b) below. (a) Sorry about your API complexity, but I think you can handle it. (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. All of this has nothing to do with whether .woman. and/or .wife. are rigid object types. Neither seems to be rigid these days. I.m talking about the concepts, not someone.s wife. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 12:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Don Baisley To: Nikolai Mansourov , "'SBVR RTF'" Date: Thu, 4 Dec 2008 22:00:31 -0800 Subject: RE: SBVR Issue: can a role range over multiple object types Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclWZb47ln6db+erTjezCtyluW/IaAAAQyEgAA1L9/A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id mB55xo3g002828 SBVR supports Nick's case of "anonymous" concepts. SBVR makes no requirement that a concept have a designation. I run into cases like this where people give an "or" expression for General Concept (e.g. 'participant' with General Concept: person or organization) or where they give a complex path expression for a reference scheme, which leaves me with a reference scheme using a role of an anonymous fact type. I've found no problem capturing all this using SBVR so far. It is not reasonable to require invention of new terms as in Nick's first case below. A person documenting a community's business vocabulary is not necessarily entitled to force new terms into the community. Nick is right that a tool can make his second case look like his first case internally. So everyone should be happy, I hope. Best regards, Don -----Original Message----- From: Nikolai Mansourov [mailto:nick@kdmanalytics.com] Sent: Thursday, December 04, 2008 3:32 PM To: edbark@nist.gov; 'keri' Cc: 'SBVR RTF' Subject: RE: SBVR Issue: can a role range over multiple object types These are exactly the choices we have: 1. You *always* have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' This is achieved by multiplicity of 'ranges over object type' being always 1 2. you can either write the above OR you can write: 'customer ranges over person or organization' you introduced a second mechanism for an on-the-fly definition of an 'anonymous' concept 'xxx is defined as 'person or organization'. This is allowed by multiplicity of 'ranges over object type' being 1 or many. My personal preference is to have an orthogonal set of mechanisms in a language. This makes a language easy to explain to the tool vendors and to the users. This in most cases leads to more disciplined products created with the use of the languages. For example, in the first case you may be encouraged to add comments, rationale, examples and notes to the concept 'legal entity'. On the other hand, in the second case the anonymous entity is a 'second class citizen'. To me this is a bit of a metaphysical challenge. I can see how other people can favour #2 as providing more power to the users of the language. Well, maybe in this case the tool vendors can (internally) reduce case #2 to #1 by introducing this anonymous concept behind the scenes, and still be happy. Just a thought. Cheers, Nick X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 05 Dec 2008 09:02:14 -0600 To: Don Baisley , Nikolai Mansourov , "'SBVR RTF'" From: "Ronald G. Ross" Subject: RE: SBVR Issue: can a role range over multiple object types At 12:00 AM 12/5/2008, Don Baisley wrote: SBVR supports Nick's case of "anonymous" concepts. SBVR makes no requirement that a concept have a designation. I run into cases like this where people give an "or" expression for General Concept (e.g. 'participant' with General Concept: person or organization) or where they give a complex path expression for a reference scheme, which leaves me with a reference scheme using a role of an anonymous fact type. I've found no problem capturing all this using SBVR so far. It is not reasonable to require invention of new terms as in Nick's first case below. A person documenting a community's business vocabulary is not necessarily entitled to force new terms into the community. Well said! An approach that forces or seems to encourage that will be a non-starter in the real (business) world. Ron P.S. Based on much painful experience(!) Nick is right that a tool can make his second case look like his first case internally. So everyone should be happy, I hope. Best regards, Don -----Original Message----- From: Nikolai Mansourov [ mailto:nick@kdmanalytics.com] Sent: Thursday, December 04, 2008 3:32 PM To: edbark@nist.gov; 'keri' Cc: 'SBVR RTF' Subject: RE: SBVR Issue: can a role range over multiple object types These are exactly the choices we have: 1. You *always* have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' This is achieved by multiplicity of 'ranges over object type' being always 1 2. you can either write the above OR you can write: 'customer ranges over person or organization' you introduced a second mechanism for an on-the-fly definition of an 'anonymous' concept 'xxx is defined as 'person or organization'. This is allowed by multiplicity of 'ranges over object type' being 1 or many. My personal preference is to have an orthogonal set of mechanisms in a language. This makes a language easy to explain to the tool vendors and to the users. This in most cases leads to more disciplined products created with the use of the languages. For example, in the first case you may be encouraged to add comments, rationale, examples and notes to the concept 'legal entity'. On the other hand, in the second case the anonymous entity is a 'second class citizen'. To me this is a bit of a metaphysical challenge. I can see how other people can favour #2 as providing more power to the users of the language. Well, maybe in this case the tool vendors can (internally) reduce case #2 to #1 by introducing this anonymous concept behind the scenes, and still be happy. Just a thought. Cheers, Nick Date: Fri, 05 Dec 2008 14:37:55 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Nikolai Mansourov CC: "'keri'" , "'SBVR RTF'" Subject: Re: SBVR Issue: can a role range over multiple object types X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB5JbtxQ015230 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229110676.06751@CZDtEfwzr+mMge4F+y+wuA X-Spam-Status: No Nikolai Mansourov wrote: These are exactly the choices we have: 1. You *always* have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' This is achieved by multiplicity of 'ranges over object type' being always 1 2. you can either write the above OR you can write: 'customer ranges over person or organization' you introduced a second mechanism for an on-the-fly definition of an 'anonymous' concept 'xxx is defined as 'person or organization'. This is allowed by multiplicity of 'ranges over object type' being 1 or many. But if you introduce a concept by definition "a person or an organization", you have a single concept. The range is not "many"; it is that one. The issue is not whether there is more than one; it is what fact types and other syntactic constructs we use to describe the range we mean. My personal preference is to have an orthogonal set of mechanisms in a language. This makes a language easy to explain to the tool vendors and to the users. This in most cases leads to more disciplined products created with the use of the languages. For example, in the first case you may be encouraged to add comments, rationale, examples and notes to the concept 'legal entity'. On the other hand, in the second case the anonymous entity is a 'second class citizen'. To me this is a bit of a metaphysical challenge. But you must realize that common business usage creates anonymous object types all the time. For example, in what you wrote above there is an object type called "products created with the use of the languages". Is that a second class citizen, a metaphysical challenge? One of the prejudices that SBVR needs to "get over" is the idea that the primary reference scheme for a concept is a designation. The primary reference scheme for a concept is a definition (whether formal or informal). Designations only work in a common speech community. Definitions tend to work in larger speech communities, and to expose misrecognitions of designations. Part of the reason we have so much trouble communicating about these issues is that we make assumptions about the use of designations. To me, anonymous types are the first-class citizens. We give some of them designations for convenience of reference. Following Don Baisley's observation, analysis reveals the relevant anonyomous types; design creates designations for them. -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: SBVR issue 13135 -- RANGES OVER Date: Fri, 5 Dec 2008 13:01:59 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR issue 13135 -- RANGES OVER Thread-Index: AclVgt/gc/XXrnt0SKCLCn/COUQ18QBBPD0QACIQ82A= From: "Terry Halpin" To: "Don Baisley" , I don.t agree with Don here. For example, he states: << Discovery that .man has wife. represents the same fact type as .man is married to woman. reveals that the .wife./.woman. role ranges over the two object types .wife. and .woman.. >> These are two different fact types. One of them is a relationship between the object types Man and Woman, while the other is a relationship between the object types Man and Wife. Wife is not the same type as Woman, but rather a role subtype of Woman. In the fact type .Man is married to Woman., we may call the first fact-role .husband. and the second fact-role .wife.. This naturally treats a fact-role as a part played in a relationship. The fact type reading .Man has Wife. is poorly worded -- the linguistic sense of .has. is too generic, leading to weak linguistic fact-role senses; and using a role name such as .wife. for the role played here by Wife is vacuous. Restricting fact-roles to range over a single type makes it easy to apply different constraints to them. For example, the fact-role played by Woman in .Man is married to Woman. would typically be optional, while the fact-role played by Wife in .Man has Wife. might not be. Cheers Terry From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Thursday, December 04, 2008 10:35 PM To: sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER The fact type .role ranges over object type. is formally defined by SBVR in terms of incorporated characteristics (the intensions) of the role and object type. You can go ahead and add a necessity statement, .Each role ranges over exactly one object type., if you can logically conclude the truth of that statement from the definition. There seems to be two use cases for SBVR here. One is for people who think of a concept system as something designed. Good design practice might limit the specification of a fact type role to range over a single object type. The other use case is for people who think of a concept system as something discovered. The first use case is more like programming and is suited to being limited by edict of the metadesigners, and the notations used can be restricted by such limits. But the discovery case deals with concept systems and vocabularies that are already in use. It is not suited to being limited by edict. And it must support gradual acquisition of information . it is not reasonable to assume that an entire concept system is assimilated all at once. Consider the work of someone learning and documenting the vocabulary of some community. They find a fact type reading .man is married to woman. and rightly conclude that the fact type.s .woman. role ranges over the object type .woman.. They discover an object type .wife. defined as .woman who is married to a man.. They find another fact type reading .man has wife. and rightly conclude that the fact type.s .wife. role ranges over the object type .wife.. But the two fact type readings are for the same fact type. The .woman. fact type role and the .wife. fact type role are the same fact type role. This is not a problem. The object type .wife. incorporates no characteristics that are not already incorporated into the .woman. role of .man is married to woman.. This is obvious from the definition of the object type .wife.. Discovery that .man has wife. represents the same fact type as .man is married to woman. reveals that the .wife./.woman. role ranges over the two object types .wife. and .woman.. A tool might choose to show only the most specific or only the most general, but that is a tool thing. The fact that the role ranges over one does not change the fact that it also ranges over the other. Discovery of the readings and the ranged over object types can happen in any order. It.s nice that we can add knowledge as it is discovered without contradicting what is already known. The open world assumption works well in discovery mode. SBVR handles the discovery use case just fine, and since I tend to find myself in the discovery case, I.m glad it does. But perhaps I have too little sympathy for people working the other use case. I am not saying that a fact type .person is married to person. is the same as the fact type .man is married to woman.. They are distinct fact types. They and their roles incorporate different characteristics. As for Mark.s .impact. (a) and (b) below. (a) Sorry about your API complexity, but I think you can handle it. (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. All of this has nothing to do with whether .woman. and/or .wife. are rigid object types. Neither seems to be rigid these days. I.m talking about the concepts, not someone.s wife. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 12:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Fri, 05 Dec 2008 16:03:16 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Terry Halpin CC: sbvr-rtf@omg.org Subject: Re: SBVR issue 13135 -- RANGES OVER X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: mB5L3G97024224 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1229115799.19844@1eAOXXA2g0FFPqtULg2rmA X-Spam-Status: No Terry Halpin wrote: The fact type reading "Man has Wife" is poorly worded -- the linguistic sense of "has" is too generic, leading to weak linguistic fact-role senses; and using a role name such as "wife" for the role played here by Wife is vacuous. I'm glad someone shares my (and Ron Ross's) disaffection with this practice. SBVR uses these "poorly worded" fact types as a matter of course, and others are beginning to emulate that practice, to my dismay. But I have thought myself the voice of one crying in the wilderness. Thanks, Terry. One can say that the fact type is 'man has wife' and it has two roles: 'man' of type 'man', and 'wife' of type 'woman'. That is, the fact type form is 'man has wife(man, woman)' or 'man:man has wife:woman'. The alternative view is the the verb is 'has wife' and it takes a subject of type 'man' and a direct object of type 'woman'. The problem with this approach is that the roles are known by their linguistic designations (subject, direct object) and not clearly by any role names. Restricting fact-roles to range over a single type makes it easy to apply different constraints to them. For example, the fact-role played by Woman in "Man is married to Woman" would typically be optional, while the fact-role played by Wife in "Man has Wife" might not be. Properly, I think what Terry means by 'optional' is that the fact type role must exist in both cases, but it needn't be explicitly defined in the case of 'woman', because it imposes no constraints on the participant beyond the named object type, as Terry says. -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@omg.org" Date: Mon, 8 Dec 2008 09:44:50 -0800 Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Thread-Topic: RE: SBVR issue 13135 -- RANGES OVER PRIME Thread-Index: AclZXKtvFF90aT/MQJKU9shA8BJ1gw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US There can be only one. Having put out the challenge to define a new fact type that relates a role to an object type for which there would, by logical necessity, be exactly one object type per role, I have come up with an idea which is admittedly half baked, but something to consider. It applies only to fact type roles, not situational roles. Here is a bad example that illustrates the idea. It is not so bad at illustrating, but like many examples, it might show poor practice, so a better example would be preferred for a final resolution. Consider these three characteristics: female is adult adult is female thing is adult female In the first, the general meaning of adult is here narrowed to its specific meaning for female. Likewise, in the second the meaning of female is narrowed to its specific meaning for adults. In any case, the three fact types are intuitively distinct, yet coextensive. In each instance of each fact type, the subject is an adult female. Making a distinction between the fact types requires that we understand a fact type role as having qualifying characteristics which are distinct from whatever characteristics are added by the fact type. For the first fact type, only being female is the qualifying characteristic of the role, even though every instance of the role is both female and adult. No distinction between qualifying characteristics of a fact type role and other characteristics that come from its fact type is not found in the definition of .fact type role.. The distinction would need to be explained and somehow fit into the definition. A more simple matter would be explaining how qualifying characterization of fact type roles is discovered from projections that define fact types. Looking at the note under .variable maps to fact type role. we see three ways characteristics are given to a fact type role. Only the first two should be considered as qualifying characteristics. Taking this approach, the EXACTLY ONE object type that is related (via RANGES OVER PRIME) to any particular fact type role would be the one whose incorporated characteristics are the qualifying characterization of the role. I will try to find time to investigate this avenue further. Best regards, Don Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 8 Dec 2008 14:05:09 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/08/2008 14:05:11 In his first email of Dec. 5, Don Baisley said: > As for Mark..s ..impact. (a) and (b) below. > (a) Sorry about your API complexity, but I think you can handle it. > (b) If tool builders learn SBVR..s definition of ..role ranges over object type.. they will understand what it means for a role to range over one, two or any number of object types. I agree that tool vendors can handle (a) if necessary. It's pretty minor compared to all the other complexities that come with SBVR. I think (b) requires tool vendors to read Don's mind, since the specification doesn't say "what it means for a role to range over ... two or any number of object types". I believe reading Don's mind is beyond what we can ask of tool vendors. Specifications should be explicit about any matter that may be in doubt. I would be satisfied with a note added to "role ranges over object type" that says something like "The semantics of a role that ranges over multiple types t1, t2, ... tn, is equivalent to the role ranging over a single (anonymous) object type that specializes all of the t1, t2, ... t object types". ------------------------------------------------------------------------------------------------------------------------------------------------------------------ In his second email of Dec. 5, Don Baisley said: > SBVR..s ..RANGE OVER. fact type does not necessitate exactly one object type for a role. If each characteristic incorporated by an object type X is incorporated by a role Y, then we must logically conclude that for any > object type Z that generalizes object type X, each characteristic incorporated by object type Z is incorporated by role Y. A rule that there always be one object type for a role would introduce a contradiction. To respond to this, I feel the need to restate what " object type Z that generalizes object type X" means. The definition of "concept1 specializes concept2" in clause 8.1.1 (with it's synonymous form "concept2 generalizes concept1"), says that "the concept1 incorporates each characteristic that is incorporated by the concept2 plus at least one differentiator ". Substituting object type X for concept1 and object type Z for concept2, we find that X must incorporate each characteristic of Z plus one differentiator. Therefore, Z has a subest of the characteristics of X. Therefore Z does not have all the incorporated characteristics of Y and cannot fill the role of Y. On the other hand, if Don had stated it the other way around, with "X generalizes object type Z", then Z could fill the role of Y. However, this whole discussion is beside the point. It is understood throughout SBVR that if an object type X can satisfy a role, then object type Z that specializes X can also satisfy the role. This is not a case of a role ranging over two object types. Role Y ranges over one object type X. Any subtype of X, such as Z, is also an X and can fill the role Y. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ In the same note, Don Baisley brought up the idea of a new "RANGE OVER PRIME" fact type. I want to make it clear that I am not proposing this in my issue. I'm not sure what Don means by this idea. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ This thread has included lots of discussion about fact type roles versus situational roles. I want to point out the duality between these and the relationship of fact types to objectifications of fact types. One example of objectification is the object type "employment" defined as "the state of affairs that person1 works for person2". Now consider the situational role "employee". One might define "employee" as "a person who works for another person". Alternatively, given the previous definition of "employment", one could define an "employee" as "the person1 of an employment". This latter shows the close linkage between situational roles and fact type objectifications. It seems to me that we use a "situational role " to name the roles of objectified fact types, and we use "fact type role" to name the roles of fact types themselves. Perhaps this observation could help "tighten up" our understanding of "situational role". Comments? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: Don Baisley To: Mark H Linehan , "sbvr-rtf@omg.org" Date: Mon, 8 Dec 2008 13:56:59 -0800 Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Thread-Topic: SBVR issue 13135 -- RANGES OVER PRIME Thread-Index: AclZaAL628yts+qMS6uaQ/qg3oM26AAFdY7w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I would be happy to resolve the issue with a note along the lines recommended by Mark. How about adding the following sentence to the end of the first note under .role ranges over object type.: Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 08, 2008 11:05 AM To: sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME In his first email of Dec. 5, Don Baisley said: > As for Mark.s .impact. (a) and (b) below. > (a) Sorry about your API complexity, but I think you can handle it. > (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. I agree that tool vendors can handle (a) if necessary. It's pretty minor compared to all the other complexities that come with SBVR. I think (b) requires tool vendors to read Don's mind, since the specification doesn't say "what it means for a role to range over ... two or any number of object types". I believe reading Don's mind is beyond what we can ask of tool vendors. Specifications should be explicit about any matter that may be in doubt. I would be satisfied with a note added to "role ranges over object type" that says something like "The semantics of a role that ranges over multiple types t1, t2, ... tn, is equivalent to the role ranging over a single (anonymous) object type that specializes all of the t1, t2, ... t object types". eply-To: From: "Donald Chapin" To: "'Terry Halpin'" , Subject: RE: issue 13135 -- SBVR RTF issue -- In SBVR's formal semantics (Clause 10), can situational roles play fact type roles? Date: Mon, 8 Dec 2008 16:40:40 -0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclVgnVenJn9ZR2ZT9ucwVltVfJQrAD/Yeeg X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0812080144 X-SpamInfo: helo-dns, Hi Terry, -------------------------------------------------------------------------------- On Sunday, November 16, 2008 6:56 AM Terry Halpin wrote: Subject: RE: Answers from Terry regarding the "Each role ranges over exactly one object type" Question . Donald: 2. In SBVR.s formal semantics (Clause 10), can situational roles play fact type roles? Terry: Regarding 2, please remind me what situational roles are in SBVR. In SBVR .fact type role. is: - role that specifically characterizes its instances by their involvement in an actuality that is an instance of a given fact type In SBVR .situational role. is both a role and an object type: - object type that corresponds to things based on their playing a part, assuming a function, or being used in some situation - General Concept: object type, role In SBVR .object type. is: - noun concept that classifies things on the basis of their common properties In SBVR .role. is: - noun concept that corresponds to things based on their playing a part, assuming a function or being used in some situation In SBVR .noun concept. is: - concept that is the meaning of a noun or noun phrase In SBVR .concept. is: - unit of knowledge (thought) created by a unique combination of characteristics If they are just role subtypes (e.g. Manager, AdultPerson) , then their instances may play fact roles. What are the criteria for .just role subtypes. and .not just role subtypes.? 1. What is the definition of .role subtype.? 2. What are the distinguishing criteria for what a .role subtype. IS and is NOT 3. What distinguishes a .role subtype. from a .fact type role. 4. How .role subtype. is related to .fact type role. besides the fact that their instances can play fact roles? a. Can a role be a .role subtype. i. - if it is not connected to any fact type in any way ii. - if it is not the generalization of one or more specifically identified fact type roles. b. Is there any other kind of relation between .role subtype. and .fact type role. Being clear about these points will contribute greatly to a successful resolution in the Thursday.s SBVR RTF meeting of questions surrounding roles in SBVR. Many Thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 12:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Reply-To: From: "Donald Chapin" To: Subject: FW: issue 13135 -- SBVR RTF issue - In SBVR's formal semantics (Clause 10), what does specifying a given object type as playing a fact type role in a given fact type mean Date: Mon, 8 Dec 2008 16:40:40 -0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclVgnVenJn9ZR2ZT9ucwVltVfJQrAEBfkoQ X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0812080144 X-SpamInfo: helo-dns, FYI -------------------------------------------------------------------------------- On Sunday, November 16, 2008 6:56 AM Terry Halpin wrote: Subject: RE: Answers from Terry regarding the "Each role ranges over exactly one object type" Question Donald: In SBVR.s formal semantics (Clause 10), does specifying a given object type as playing a fact type role in a given fact type mean that: a. all instances (objects) of that object type are able by definition to play the role; i.e. there is nothing stopping them from playing the role, and b. no other instance (objects) may play that fact type role. Terry: Regarding 1, the answer is yes, so long as you understand that (b) allows instances of subtypes of the object type to play the role -- because each instance of a subtype is also an instance of its supertype(s). At this stage, we distinguish fact-roles from one another if the are "played" by different types, even if they have the same semantics. For example, we treat the first roles of the fact types "Person has Familyname" and "Person has GivenName" as distinct even though they mean the same ("possesses"). One reason for this is to allow us to apply different constraints to them. For example the "has" role in "Person has Familyname" has a single-role uniqueness constraint on it but the "has" role in "Person has GivenName" doesn't. . Cheers Terry -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 12:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Date: Tue, 9 Dec 2008 08:04:20 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR issue 13135 -- RANGES OVER PRIME Thread-Index: AclZaAL628yts+qMS6uaQ/qg3oM26AAFdY7wABNovNs= From: "Sjir Nijssen" To: "Don Baisley" , "Mark H Linehan" , Dear all, During 2008 we have given more than 60 days of SBVR intensive training. During that training we initially concentrate on a well selected subset of SBVR. Participants love it. It turns out when we try to teach the complexities of SBVR, the attitude rapidly changes and not for the better. The proposal below is a step into the complexity direction. SBVR has more than enough complexities. Let us learn from history that teaches us that complexities die sooner that solid simplicities. Please accept the clean proposal of Terry/Mark, if you want to support SBVR, is my professional opinion. Kind regards Sjir -------------------------------------------------------------------------------- Van: Don Baisley [mailto:Don.Baisley@microsoft.com] Verzonden: ma 8-12-2008 22:56 Aan: Mark H Linehan; sbvr-rtf@omg.org Onderwerp: RE: SBVR issue 13135 -- RANGES OVER PRIME I would be happy to resolve the issue with a note along the lines recommended by Mark. How about adding the following sentence to the end of the first note under .role ranges over object type.: Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 08, 2008 11:05 AM To: sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME In his first email of Dec. 5, Don Baisley said: > As for Mark.s .impact. (a) and (b) below. > (a) Sorry about your API complexity, but I think you can handle it. > (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. I agree that tool vendors can handle (a) if necessary. It's pretty minor compared to all the other complexities that come with SBVR. I think (b) requires tool vendors to read Don's mind, since the specification doesn't say "what it means for a role to range over ... two or any number of object types". I believe reading Don's mind is beyond what we can ask of tool vendors. Specifications should be explicit about any matter that may be in doubt. I would be satisfied with a note added to "role ranges over object type" that says something like "The semantics of a role that ranges over multiple types t1, t2, ... tn, is equivalent to the role ranging over a single (anonymous) object type that specializes all of the t1, t2, ... t object types". . From: Don Baisley To: Sjir Nijssen , "sbvr-rtf@omg.org" Date: Tue, 9 Dec 2008 07:23:51 -0800 Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Thread-Topic: SBVR issue 13135 -- RANGES OVER PRIME Thread-Index: AclZaAL628yts+qMS6uaQ/qg3oM26AAFdY7wABNovNsAEV0zUA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Sjir, I agree with you that we should shoot for simplicity over complexity. Adding a new fact type to relate object types to roles will add complexity, especially if it is only understood in terms of poor examples that tend to not be used in practice. So I am happy to abandon the search for a new fact type and do as Mark suggests: add a note. We cannot add a necessity unless we can prove it is true. The necessity people have suggested is easily proved false. The only clean proposal offered so far is a note, as suggested by Mark. Are you OK with that? Best regards, Don From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: Monday, December 08, 2008 11:04 PM To: Don Baisley; Mark H Linehan; sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Dear all, During 2008 we have given more than 60 days of SBVR intensive training. During that training we initially concentrate on a well selected subset of SBVR. Participants love it. It turns out when we try to teach the complexities of SBVR, the attitude rapidly changes and not for the better. The proposal below is a step into the complexity direction. SBVR has more than enough complexities. Let us learn from history that teaches us that complexities die sooner that solid simplicities. Please accept the clean proposal of Terry/Mark, if you want to support SBVR, is my professional opinion. Kind regards Sjir -------------------------------------------------------------------------------- Van: Don Baisley [mailto:Don.Baisley@microsoft.com] Verzonden: ma 8-12-2008 22:56 Aan: Mark H Linehan; sbvr-rtf@omg.org Onderwerp: RE: SBVR issue 13135 -- RANGES OVER PRIME I would be happy to resolve the issue with a note along the lines recommended by Mark. How about adding the following sentence to the end of the first note under .role ranges over object type.: Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 08, 2008 11:05 AM To: sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME In his first email of Dec. 5, Don Baisley said: > As for Mark.s .impact. (a) and (b) below. > (a) Sorry about your API complexity, but I think you can handle it. > (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. I agree that tool vendors can handle (a) if necessary. It's pretty minor compared to all the other complexities that come with SBVR. I think (b) requires tool vendors to read Don's mind, since the specification doesn't say "what it means for a role to range over ... two or any number of object types". I believe reading Don's mind is beyond what we can ask of tool vendors. Specifications should be explicit about any matter that may be in doubt. I would be satisfied with a note added to "role ranges over object type" that says something like "The semantics of a role that ranges over multiple types t1, t2, ... tn, is equivalent to the role ranging over a single (anonymous) object type that specializes all of the t1, t2, ... t object types". . Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Date: Tue, 9 Dec 2008 18:40:11 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR issue 13135 -- RANGES OVER PRIME Thread-Index: AclZaAL628yts+qMS6uaQ/qg3oM26AAFdY7wABNovNsAEV0zUAAFD6G3 From: "Sjir Nijssen" To: "Don Baisley" , Dear Don, Thank you very much for your statement : shoot for simplicity over complexity. With respect to your statement "is easily proved false" I happen to disagree. Let me say the following: a new standard can be developed in at least four ways: 1. Base it upon a standaard that some people call a biran others a koble. In that case there is no need for logical reasoning. 2. Propound elements directly at the generic conceptual schema level. 3. Propound elements directly at the generic level with occasional illustrations at the domain specific level. 4. Always start with a representavive set of ground facts, both permitted and not permitted, derive from there the domain specific conceptual schema and apply the same derivation procedure from the domain specific conceptual schema to arrive at the generic schema. My religion only permits me to believe in 4. If we would apply 4 to SBVR then to arrive at simplicity will keep us quite some time of the street. I have not seen any consistent reasoning using business practice 4 that would contradict: Each fact type role ranges over exactly one object type. I hope the majority of the votes will go in the direction of making SBVR solidly simple yet adequate for the job. Kind regards Sjir -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Tue 12/9/2008 4:23 PM To: Sjir Nijssen; sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Hi Sjir, I agree with you that we should shoot for simplicity over complexity. Adding a new fact type to relate object types to roles will add complexity, especially if it is only understood in terms of poor examples that tend to not be used in practice. So I am happy to abandon the search for a new fact type and do as Mark suggests: add a note. We cannot add a necessity unless we can prove it is true. The necessity people have suggested is easily proved false. The only clean proposal offered so far is a note, as suggested by Mark. Are you OK with that? Best regards, Don From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: Monday, December 08, 2008 11:04 PM To: Don Baisley; Mark H Linehan; sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME Dear all, During 2008 we have given more than 60 days of SBVR intensive training. During that training we initially concentrate on a well selected subset of SBVR. Participants love it. It turns out when we try to teach the complexities of SBVR, the attitude rapidly changes and not for the better. The proposal below is a step into the complexity direction. SBVR has more than enough complexities. Let us learn from history that teaches us that complexities die sooner that solid simplicities. Please accept the clean proposal of Terry/Mark, if you want to support SBVR, is my professional opinion. Kind regards Sjir -------------------------------------------------------------------------------- Van: Don Baisley [mailto:Don.Baisley@microsoft.com] Verzonden: ma 8-12-2008 22:56 Aan: Mark H Linehan; sbvr-rtf@omg.org Onderwerp: RE: SBVR issue 13135 -- RANGES OVER PRIME I would be happy to resolve the issue with a note along the lines recommended by Mark. How about adding the following sentence to the end of the first note under .role ranges over object type.: Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 08, 2008 11:05 AM To: sbvr-rtf@omg.org Subject: RE: SBVR issue 13135 -- RANGES OVER PRIME In his first email of Dec. 5, Don Baisley said: > As for Mark.s .impact. (a) and (b) below. > (a) Sorry about your API complexity, but I think you can handle it. > (b) If tool builders learn SBVR.s definition of .role ranges over object type. they will understand what it means for a role to range over one, two or any number of object types. I agree that tool vendors can handle (a) if necessary. It's pretty minor compared to all the other complexities that come with SBVR. I think (b) requires tool vendors to read Don's mind, since the specification doesn't say "what it means for a role to range over ... two or any number of object types". I believe reading Don's mind is beyond what we can ask of tool vendors. Specifications should be explicit about any matter that may be in doubt. I would be satisfied with a note added to "role ranges over object type" that says something like "The semantics of a role that ranges over multiple types t1, t2, ... tn, is equivalent to the role ranging over a single (anonymous) object type that specializes all of the t1, t2, ... t object types". . Subject: RE: issue 13135 -- SBVR RTF issue -- In SBVR's formal semantics (Clause 10), can situational roles play fact type roles? Date: Tue, 9 Dec 2008 11:43:19 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13135 -- SBVR RTF issue -- In SBVR's formal semantics (Clause 10), can situational roles play fact type roles? Thread-Index: AclVgnVenJn9ZR2ZT9ucwVltVfJQrAD/YeegACp+xlA= From: "Terry Halpin" To: , Dear Donald It sounds like SBVR.s situational role is what I call a role subtype. For me, a fact-role (or fact-type role) is a part played in a fact type, e.g. The fact type .Person works for Company. includes a binary predicate .. works for .. with 2 object-placeholders for the 2 fact-roles being played. The fact-role played by Person could be named .worker. and the fact-role played by Company could be called .employer.. These role names are understood within the context of the fact type. For example, I could have another fact type .Academic works for University., with two different fact-roles, each of which could be called .worker. and .employer.. I might want to apply different constraints to the different fact-roles (e.g. I might require an academic to work for at most one university while allowing that a person may work for many companies). In this case the worker fact-role in .Academic works for University. has a simple uniqueness constraint on it while the worker role in .Person works for Company. does not. Requiring each fact-role to range over one object type makes it easy to clearly specify what constraints apply to a fact-role. If I instead said the .same worker role. ranges over both Academic and Person, that would confuse things. Of course, Academic is a subtype of Person, so the worker role played by (instances of) Academic is indirectly-played by (instances of) Person. I use .played by. in a direct sense, and it is in that direct sense that I claim that a fact-role ranges over only one object type. I divide object types into rigid types and role types. Instances of a rigid type (e.g. Person) must remain in that type for their whole lifetime. In contrast, instances may move into or out of role types (e.g. Academic) at different times in their lifetime. More fine-grained distinctions can be made (e.g. between role types and phases) but I don.t think they are worth making. This simple scheme seems to work well in practice. Hope this helps Terry From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Monday, December 08, 2008 5:41 PM To: Terry Halpin; sbvr-rtf@omg.org Subject: RE: issue 13135 -- SBVR RTF issue -- In SBVR's formal semantics (Clause 10), can situational roles play fact type roles? Hi Terry, -------------------------------------------------------------------------------- On Sunday, November 16, 2008 6:56 AM Terry Halpin wrote: Subject: RE: Answers from Terry regarding the "Each role ranges over exactly one object type" Question . Donald: 2. In SBVR.s formal semantics (Clause 10), can situational roles play fact type roles? Terry: Regarding 2, please remind me what situational roles are in SBVR. In SBVR .fact type role. is: - role that specifically characterizes its instances by their involvement in an actuality that is an instance of a given fact type In SBVR .situational role. is both a role and an object type: - object type that corresponds to things based on their playing a part, assuming a function, or being used in some situation - General Concept: object type, role In SBVR .object type. is: - noun concept that classifies things on the basis of their common properties In SBVR .role. is: - noun concept that corresponds to things based on their playing a part, assuming a function or being used in some situation In SBVR .noun concept. is: - concept that is the meaning of a noun or noun phrase In SBVR .concept. is: - unit of knowledge (thought) created by a unique combination of characteristics If they are just role subtypes (e.g. Manager, AdultPerson) , then their instances may play fact roles. What are the criteria for .just role subtypes. and .not just role subtypes.? 1. What is the definition of .role subtype.? 2. What are the distinguishing criteria for what a .role subtype. IS and is NOT 3. What distinguishes a .role subtype. from a .fact type role. 4. How .role subtype. is related to .fact type role. besides the fact that their instances can play fact roles? a. Can a role be a .role subtype. i. - if it is not connected to any fact type in any way ii. - if it is not the generalization of one or more specifically identified fact type roles. b. Is there any other kind of relation between .role subtype. and .fact type role. Being clear about these points will contribute greatly to a successful resolution in the Thursday.s SBVR RTF meeting of questions surrounding roles in SBVR. Many Thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 12:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Don Baisley To: "sbvr-rtf@omg.org" Date: Thu, 11 Dec 2008 18:10:56 -0800 Subject: SBVR-RTF issue 13135 Thread-Topic: SBVR-RTF issue 13135 Thread-Index: Aclb/t5z3mYlCQs9SXeeJrYSJOZvkg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Donald asked me to write up the following note for the .ranges over. fact type. I tried to capture the extension and intension perspectives and contrast with ranging over a single type defined using .OR.. Note to add after the existing note under .role ranges over object type.: Given two object types T1 and T2, saying a role ranges over .T1 or T2. means that the role ranges over a third object type meant by .T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2. In contrast, saying a role ranges over T1 and separately that the same role ranges over T2 indicates that all instances of the role are in the intersection of the extensions of T1 and T2. Speaking in terms of intension, saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. This is longer than I wanted, but I hope it is enough to cover our different points of view. Best regards, Don Subject: RE: SBVR-RTF issue 13135 Date: Fri, 12 Dec 2008 07:36:11 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR-RTF issue 13135 thread-index: Aclb/t5z3mYlCQs9SXeeJrYSJOZvkgAI1gJ8 From: "Sjir Nijssen" To: "Don Baisley" , To all, The reason that there is so much eliminatable complexity is the procedure that is followed to arrive at Clause 8. In my email of dec 9, 2008, I have suggested to use a well defined procedure to start at the level of the ground facts, go from there to the domain specific cs using a well described procedure and go from there to the generic cs using the same well defined procedure. I strongly support Don's statement "shoot for simplicity over complexit." as he stated in his email of dec 9. However the text proposed below is using the same procedure that has resulted in the current complexity and is therefor in the wrong direction. I am sorry to express that I am opposed to this addition. Kind regards Sjir -------------------------------------------------------------------------------- Van: Don Baisley [mailto:Don.Baisley@microsoft.com] Verzonden: vr 12-12-2008 3:10 Aan: sbvr-rtf@omg.org Onderwerp: SBVR-RTF issue 13135 Donald asked me to write up the following note for the .ranges over. fact type. I tried to capture the extension and intension perspectives and contrast with ranging over a single type defined using .OR.. Note to add after the existing note under .role ranges over object type.: Given two object types T1 and T2, saying a role ranges over .T1 or T2. means that the role ranges over a third object type meant by .T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2. In contrast, saying a role ranges over T1 and separately that the same role ranges over T2 indicates that all instances of the role are in the intersection of the extensions of T1 and T2. Speaking in terms of intension, saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. This is longer than I wanted, but I hope it is enough to cover our different points of view. Best regards, Don Subject: Re: SBVR-RTF issue 13135 To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Fri, 12 Dec 2008 15:37:33 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/12/2008 15:37:30 This is not very clear. More importantly, this note -- while technically correct -- applies to object types in general, not just to (situational) roles. We should find a way to explain "concept2 generalizes concept1" where multiple concept2's generalize the same concept1. We should describe this once somewhere in a way that applies not just to roles but all object types. Consider these examples: 1. On page 147: situational role Definition: object type that corresponds to things based on their playing a part, assuming a function, or being used in some situation General Concept: object type, role Concept Type: concept type This example shows the use of what in the OO world is called "multiple inheritance", applied to a concept type. Something is a "situational role" only if it is all three of (a) an "object type", (b) a "role", and (c) "corresponds to things based on their playing a part, assuming a function, or being used in some situation". In other words -- as described in Don's proposed note -- a thing is a situational role only if it satisfies the union of the incorporated characteristics of (a) thru (c). 2. Page 49: closed logical formulation Definition: logical formulation that is a closed semantic formulation The definition means the same thing as "General Concept: logical formulation, closed semantic formulation". The meaning is understood as in #1 above. 3. Page 147: contextualized concept Definition: role or facet This is an extensional definition. A thing is a "contextualized concept" if its characteristics satisfy the definitions of either "role" or of "facet". Compare with Don's text that reads "Given two object types T1 and T2, saying a role ranges over ..T1 or T2. means that the role ranges over a third object type meant by ..T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2." "Extensional definition" is defined explicitly on page 139 and in the text of "concept incorporates characteristic " on page 23. As far as I know, "multiple inheritance" is not defined anywhere in the spec. Nowhere is it clear whether "extensional definition" and "multiple inheritance" apply to situational roles as well as other kinds of object types. Furthermore, annex C does not say how one defines a situational role, and does not discuss how one specifies multiple inheritance or extensional definition in a glossary entry. Therefore, I want to propose that we think about this problem on a larger scale. I think a good solution would include these components: a) Formally specify what "multiple inheritance" and "extensional definition" mean. I would prefer to see this in a new section of clause 10 (where other formal semantics are given), rather than scattered in notes (which are not normative) in various places throughout the spec. This might also be a good place for a comprehensive description of "necessary" versus "incorporated" versus "essential" versus "implied" characteristics. b) Extend the discussion in clause C.3.2.1 "Definition of an Object Type" to describe how "Structured English" definitions specify "multiple inheritance" and "extensional definition". Currently, you have to guess, and I bet most readers don't realize that these are possible. c) Correct the numbering of the second clause C.3.2.2 "Definition of a Fact Type" to be C.3.2.3. d) Add a new clause C.3.2.2.4 "Definition of a Situational Role" that makes it clear that for situational role entries: - "General Concept: X" means that the situational role "ranges over" X - Ditto for any general concepts specified in the Definition caption - Definitions of situational roles can use both "multiple inheritance" and "extensional definitions". e) Add text to C.3.5 "General Concept" to say that multiple concepts can be listed, separated by commas, to mean "multiple inheritance". In Structured English, "fact type roles" do not have glossary entries and thus do not have their own definitions. This is consistent with the fact that "fact type roles" are not "object types" and thus cannot have either "multiple inheritance" or "extensional definitions". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Don Baisley Don Baisley 12/11/2008 09:10 PM To "sbvr-rtf@omg.org" cc Subject SBVR-RTF issue 13135 Donald asked me to write up the following note for the ..ranges over. fact type. I tried to capture the extension and intension perspectives and contrast with ranging over a single type defined using ..OR.. Note to add after the existing note under ..role ranges over object type.: Given two object types T1 and T2, saying a role ranges over ..T1 or T2. means that the role ranges over a third object type meant by ..T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2. In contrast, saying a role ranges over T1 and separately that the same role ranges over T2 indicates that all instances of the role are in the intersection of the extensions of T1 and T2. Speaking in terms of intension, saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. This is longer than I wanted, but I hope it is enough to cover our different points of view. Best regards, Don pic09084.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 12 Dec 2008 10:41:44 -1000 Subject: Re: SBVR-RTF issue 13135 From: keri To: Don Baisley , SBVR RTF Thread-Topic: SBVR-RTF issue 13135 Thread-Index: Aclb/t5z3mYlCQs9SXeeJrYSJOZvkgAmyzI9 Don, Thank you for this summary . you have captured the various perspectives covered in yesterday's far-ranging face-to-face/telcon discussion. If folks think this is too lengthy for an in-line Note I'd be happy to add the explanatory narrative into Annex D (D.2.2). And the existing Note could refer to that explanation (or not). Keri On 12/11/08 4:10 PM, "Don Baisley" wrote: Donald asked me to write up the following note for the .ranges over. fact type. I tried to capture the extension and intension perspectives and contrast with ranging over a single type defined using .OR.. Note to add after the existing note under .role ranges over object type.: Given two object types T1 and T2, saying a role ranges over .T1 or T2. means that the role ranges over a third object type meant by .T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2. In contrast, saying a role ranges over T1 and separately that the same role ranges over T2 indicates that all instances of the role are in the intersection of the extensions of T1 and T2. Speaking in terms of intension, saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. This is longer than I wanted, but I hope it is enough to cover our different points of view. Best regards, Don From: Don Baisley To: keri , SBVR RTF Date: Fri, 12 Dec 2008 13:16:12 -0800 Subject: RE: SBVR-RTF issue 13135 Thread-Topic: SBVR-RTF issue 13135 Thread-Index: Aclb/t5z3mYlCQs9SXeeJrYSJOZvkgAmyzI9AAEmcHA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Keri, Good idea. I.d be happy to see the note put into D rather than clause 8. Don From: keri [mailto:keri_ah@mac.com] Sent: Friday, December 12, 2008 12:42 PM To: Don Baisley; SBVR RTF Subject: Re: SBVR-RTF issue 13135 Don, Thank you for this summary . you have captured the various perspectives covered in yesterday's far-ranging face-to-face/telcon discussion. If folks think this is too lengthy for an in-line Note I'd be happy to add the explanatory narrative into Annex D (D.2.2). And the existing Note could refer to that explanation (or not). Keri On 12/11/08 4:10 PM, "Don Baisley" wrote: Donald asked me to write up the following note for the .ranges over. fact type. I tried to capture the extension and intension perspectives and contrast with ranging over a single type defined using .OR.. Note to add after the existing note under .role ranges over object type.: Given two object types T1 and T2, saying a role ranges over .T1 or T2. means that the role ranges over a third object type meant by .T1 or T2. and implies that instances of the role are always within the union of the extensions of T1 and T2. In contrast, saying a role ranges over T1 and separately that the same role ranges over T2 indicates that all instances of the role are in the intersection of the extensions of T1 and T2. Speaking in terms of intension, saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types. This is longer than I wanted, but I hope it is enough to cover our different points of view. Best regards, Don DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MIMEOLE:In-Reply-To:Thread-Index; b=NvxdJDCt23GsYFPkx5uV4tXl2vW+wfVH/kDGthQUTpKJHIowYhoz/qLVR1ucp73Mc2cPDu50xi1XIa5Buc2yUEGV3pd0K3fSRAxe/NWuLjvbCXIRTZ8eCJbxZLhi6WTW4fWOWAGySeUVc3hsCwzrAxrixqZyNNpk3zhYlBOTsr8= ; X-YMail-OSG: h.5Gth0VM1lQ6AR7tmXYYcU2i8PzgzkdqZYMbLQyuVHqzr3RTBwREfEmaU84t3G0aBkxfPIHXp9JauyXT2kSoX56t8D.Uf7SemvcMFcRQ_5HeJazXFhY4fIjHdTR.JgUNDmbksbog9SEEVG6Q1kNuZHz9aEcCOTIAXubuKw7WQJDEQ2hpUtJWa3RFHvjpb7K2K7CobnZWdb3mFI7XRA9YDZ0lA-- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issue 13135 -- SBVR RTF issue Date: Fri, 30 Jan 2009 12:56:18 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclVgnVenJn9ZR2ZT9ucwVltVfJQrAtVXqaA Attached is the Issue 13135 resolution which was agreed at the SBVR RTF face to face meeting, subject to simpler wording to be provided by Don Baisley. We need to: a. Decide on which of the two wording options is most clear. b. Decide if clarifying wording needs to go in Annex D or else where. There are a couple of points about emails after the meeting: 1. We must either restrict role ranges over object type to one object type or add clarifying wording in the normative part of the spec. 2. There was a clear consensus in the meeting for the adding clarifying meaning rather than restrict this fact type to one object type. That is the way this resolution reads. 3. We can make it clear in Clause 10 that, for formal logic interpretation purposes, in the fact type type of individual plays part as ground fact type role (Issue 13139 Resolution) only one type of individual plays part as a given ground fact type role . Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, December 03, 2008 8:05 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13135 -- SBVR RTF issue Subject: SBVR Issue: can a role range over multiple object types To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 3 Dec 2008 14:51:58 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/03/2008 14:51:58 The fact type "role ranges over object type " appears in section 8.1.1. As defined -- due to the "open world" aspect of SBVR -- it appears that a role can range over multiple object types, which does not make much sense. But if you look at the MeaningAndRepresentation-model.xml file, you will find confirmation that a role can range over multiple object types. This has a downstream impact in the MDT-SBVR open source Eclipse project, where the .xml file is converted directly to an EMF model and a matching Java implementation. The API for setting an instance of this fact type permits each role to range over multiple object types. This has two impacts: (a) adds complexity to the API; (b) forces tool vendors to try to figure out the semantics of one role that ranges over multiple object types. Either the specification should explain what it means for a role to range over multiple object types, or it should introduce a Necessity: "each role ranges over exactly one object type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org te: Fri, 30 Jan 2009 17:53:05 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: sbvr-rtf@omg.org Subject: Re: issue 13135 -- SBVR RTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n0UMr5jL032081 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1233960787.32957@q4QecEGreZw7JICxU7Ve4Q X-Spam-Status: No Donald Chapin wrote: Attached is the Issue 13135 resolution which was agreed at the SBVR RTF face to face meeting, subject to simpler wording to be provided by Don Baisley. We need to: a. Decide on which of the two wording options is most clear. b. Decide if clarifying wording needs to go in Annex D or else where. I attach a marked-up version. I think the beginning of Don's Option 2 text answers the question that was uppermost in the minds of the people who raised the issue, and to that end, I have suggested some additional text for the Note that is the end of Option 1. OTOH, I don't really like Option 2 because it is too technical in areas where Option 1 (by being less pedantic) is easier to understand, and because its phrasing of the missing concept suggests a notation (R ranges over T1 or T2) that isn't supported by SBVR SE. You can see from the text I propose what that formulation really has to look like. Underlying this is the fact that SBVR says you can define a concept as a union of other concepts, but doesn't actually provide a formulation for that in clause 9 (it can, of course, be phrased as the obvious projection) nor a keyword for that in Annex C. -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." Issue 13135 Resolution 2009-01-30-ejb.doc From: Don Baisley To: "sbvr-rtf@omg.org" Date: Fri, 5 Dec 2008 17:50:55 -0800 Subject: RE: SBVR issue 13135 -- RANGES OVER Thread-Topic: SBVR issue 13135 -- RANGES OVER Thread-Index: AclVgt/gc/XXrnt0SKCLCn/COUQ18QBBPD0QACIQ82AACXvTkA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US SBVR currently has a .RANGE OVER. fact type by which a role is related to an object type as follows: Each characteristic that is incorporated by the object type is incorporated by the role. I.ll leave out the fact type.s reading to avoid confusion with other notions that have been under discussion. I.ll also avoid real examples since, even though they actually occur, they might distract our discussion towards best practice, which is not related to this issue. The issue raised was about necessity, not best practice. SBVR.s .RANGE OVER. fact type does not necessitate exactly one object type for a role. If each characteristic incorporated by an object type X is incorporated by a role Y, then we must logically conclude that for any object type Z that generalizes object type X, each characteristic incorporated by object type Z is incorporated by role Y. A rule that there always be one object type for a role would introduce a contradiction. If there is interest in having a fact type in SBVR that relates a role to exactly one object type, it will need to be a different fact type. Whether the existing fact type should remain is another matter. Before starting the add-versus-replace discussion, I would like to see what the other fact type is. Perhaps it will do the job that the existing fact type is doing now. I have been working on software that discovers concept systems from business glossaries. If the software finds terms .x., .y. and .z. and fact type forms .x v1 y. and .x v2 z., it draws the following conclusions, which all correspond to instances of SBVR.s .RANGE OVER. fact type. It is just as well that these are not familiar terms, because the software must deal with terms unfamiliar to it. The software has no common sense or intuition. 1. All characteristics incorporated by the object type .x. are incorporated by the .x. role in .x v1 y.. 2. All characteristics incorporated by the object type .y. are incorporated by the .y. role in .x v1 y.. 3. All characteristics incorporated by the object type .x. are incorporated by the .x. role in .x v2 z.. 4. All characteristics incorporated by the object type .z. are incorporated by the .z. role in .x v2 z.. If the business glossary says that .x v1 y. and .x v2 z. are synonymous forms of the same fact type, then the software concludes that the .y. role in .x v1 y. is the same fact type role as the .z. role in .x v2 z.. This discovery does not introduce any contradiction. The four facts listed above still hold. Alternatively, .x v1 y. and .x v2 z. might each have definitions given. If the definitions have logically equivalent semantic formulations, then the software should conclude that they define the same fact type, even without the glossary saying they are synonymous. If a new .RANGE OVER PRIME. fact type is defined for SBVR, how will it relate to the characteristics incorporated in a role and an object type? Will the new fact type choose one object type by community decision . a design choice (which would perhaps make it a ternary fact type with a .community. or .body of shared .. role), or is there some way of knowing which object type is the one object type for a role based on incorporated characteristics or based on something that can be discovered from semantic formulations of definitions? It would be preferable to me that a new .RANGE OVER PRIME. fact type be defined in terms of intrinsic properties of roles and object types. My software uses SBVR.s .RANGES OVER. fact type. It works for my purpose, which is not the same purpose that others might have. I look to the people who want a different fact type to define it. Best regards, Don X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 05 Dec 2008 09:02:14 -0600 To: Don Baisley , Nikolai Mansourov , "'SBVR RTF'" From: "Ronald G. Ross" Subject: RE: SBVR Issue: can a role range over multiple object types At 12:00 AM 12/5/2008, Don Baisley wrote: SBVR supports Nick's case of "anonymous" concepts. SBVR makes no requirement that a concept have a designation. I run into cases like this where people give an "or" expression for General Concept (e.g. 'participant' with General Concept: person or organization) or where they give a complex path expression for a reference scheme, which leaves me with a reference scheme using a role of an anonymous fact type. I've found no problem capturing all this using SBVR so far. It is not reasonable to require invention of new terms as in Nick's first case below. A person documenting a community's business vocabulary is not necessarily entitled to force new terms into the community. Well said! An approach that forces or seems to encourage that will be a non-starter in the real (business) world. Ron P.S. Based on much painful experience(!) Nick is right that a tool can make his second case look like his first case internally. So everyone should be happy, I hope. Best regards, Don -----Original Message----- From: Nikolai Mansourov [ mailto:nick@kdmanalytics.com] Sent: Thursday, December 04, 2008 3:32 PM To: edbark@nist.gov; 'keri' Cc: 'SBVR RTF' Subject: RE: SBVR Issue: can a role range over multiple object types These are exactly the choices we have: 1. You *always* have to write: 'customer ranges over legal entity' where 'legal entity' is defined as 'person or organization' This is achieved by multiplicity of 'ranges over object type' being always 1 2. you can either write the above OR you can write: 'customer ranges over person or organization' you introduced a second mechanism for an on-the-fly definition of an 'anonymous' concept 'xxx is defined as 'person or organization'. This is allowed by multiplicity of 'ranges over object type' being 1 or many. My personal preference is to have an orthogonal set of mechanisms in a language. This makes a language easy to explain to the tool vendors and to the users. This in most cases leads to more disciplined products created with the use of the languages. For example, in the first case you may be encouraged to add comments, rationale, examples and notes to the concept 'legal entity'. On the other hand, in the second case the anonymous entity is a 'second class citizen'. To me this is a bit of a metaphysical challenge. I can see how other people can favour #2 as providing more power to the users of the language. Well, maybe in this case the tool vendors can (internally) reduce case #2 to #1 by introducing this anonymous concept behind the scenes, and still be happy. Just a thought. Cheers, Nick User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 08 Dec 2008 09:48:15 -1000 Subject: Re: State <-- SBVR Issue: can a role range over multiple object types From: keri To: Paul Vincent , SBVR RTF Thread-Topic: State <-- SBVR Issue: can a role range over multiple object types Thread-Index: AclWTrft9lPIs8JBEd2gpAARJM+CggACUjlQAMV6Aws= Hi, Paul . a couple of thoughts that have continued to cook since you wrote your note. I can see now where some things I wrote could have gotten you (and perhaps Ed) to think of the 'state' aspect of 'role'. Indeed, wearing my Model Systems hat there is the 'life history' view where Fluffy is born as an 'animal' and then (possibly at the same time or perhaps latter) in her life as a 'pet' ... and then maybe dies and is born in (out of and into) her 'pet' life (as she becomes homeless and is then adopted), until she finally dies in her 'animal' life. That is an interesting way to regard and understand 'role' in this non-fact-type-role sense. What I was thinking of in the 'perception' sense was not in this state/over-time sense but rather when from a single point-in-time where Fluffy is a 'pet' (and, of course, simulatenously an 'animal') -- 'regard' rather than 'perceive' might be a better term. From this perspective, there could be a rule that regards Fluffy in her pet-ness . say, our condo rule that says, "No Pets Allowed!" And then Fluffy could (at the same time) be covered in her animal-ness by a rule/policy that says, "Be kind of animals . no animal abuse." In both cases, these are applying to one-and-the-same Fluffy ... but each regards her in a different role/essence sense. ~ Keri On 12/4/08 11:42 AM, "Paul Vincent" wrote: Hi Keri . that.s interesting. Might it be your .perception. that changes state from understanding Fluffy (.s role) as a pet, from just some other annoying animal (role). ? Isn.t .state. in SBVR is just considered another fact type? [Sorry to digress. but at Tibco we use state modeling in our CEP product to help model situations like .changeable roles. . an IT perspective, of course]. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 04 December 2008 20:27 To: Ed Barkmeyer; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > There is no formal definition of 'role' here. And SBVR has no notion of > 'steps into'. Keri is talking about a change of state. A world is. A > later world is a different world. SBVR has no temporal concept, no > concept of ordering worlds. So this concept, which relies on those > notions, is out of scope in SBVR v1. But that doesn't mean we have to > discard it. It just means that the formal notions its definition needs > are unavailable. Let me try again. I agree that the "steps into" wording is not SBVR-speak. But the notion I was talking about is not state change. Perhaps if we can get on the same page about the basics of what this non-fact-type-role is about then we can build on that and sort out how 'ranges over' fits in. In Clause 11 we attempted make a basic distinction between 'fundamental' and 'situational' -- concepts where it's part of the 'essence' of a thing to be one of those vs. concepts where its things are perceived to be instances situationally. Kinda hard to say this formally ... "steps into the role" ("plays the role") just seems easier to grasp. This isn't something that the SBVRites made up out of whole cloth. E.g., Sowa talks about 'pet' (role) vs. 'animal' (fundamental). Sorry -- I don't have my Sowa book handy to recall his particular terminology. In any case, Fluffy does not undergo a state change when I perceive her as a pet because of her situation. And whether or not Fluffy is playing that role she is fundamentally . as part of her essence . always an animal (cat). Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 08 Dec 2008 09:51:28 -1000 Subject: Re: SBVR Issue: can a role range over multiple object types From: keri To: Ed Barkmeyer , SBVR RTF Thread-Topic: SBVR Issue: can a role range over multiple object types Thread-Index: AclZblvomnX17sVhEd2YVAARJM+Cgg== On 12/4/08 11:22 AM, "Ed Barkmeyer" wrote: >> situational role ranges over object type >> means that things that correspond to the object type are eligible to >> take on the situational role. That intent is inclusive. There may be >> other things that are also eligible. > > I should have mentioned: > > The inclusive intent is only useful if there is a presumed prohibition: > nothing can be a customer except what we include. The SBVR default is > permission: "Any thing can be a customer, unless there is some rule that > restricts it." So saying that 'customer ranges over person' is actually > just stating an advice, or an example. Hi, Ed, On another point that has churned for me a bit ... namely, how does this all work out in a 'permissive' (open) world where, as you suggest, use of this fact type would be seen as an advice. That was nagging at me, until the penny dropped.... Since this is found in the context of a definition then the default is that it is required. The parallel case (easier? to understand) is that when I write a definition for 'cat' I would begin the definition with 'animal that blahblahblah". This specifies that any cat must also be an animal (and only an animal). So, when I write my definition of 'customer' as below: customer Concept Type: role Definition: person or organization that blahblahblah I am specifying that the concept 'customer' is a role that is played by either (and only) a person or an organization. So this does make it 'inclusive' -- by definition, nothing can be a customer except what has been specified. Whew! You had me worried.... ~ Keri Subject: RE: State <-- SBVR Issue: can a role range over multiple object types Date: Tue, 9 Dec 2008 07:31:39 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State <-- SBVR Issue: can a role range over multiple object types Thread-Index: AclWTrft9lPIs8JBEd2gpAARJM+CggACUjlQAMV6AwsAKSzFMA== Priority: Non-Urgent From: "Paul Vincent" To: "keri" , "SBVR RTF" X-OriginalArrivalTime: 09 Dec 2008 15:31:42.0386 (UTC) FILETIME=[3C922920:01C95A13] Hi Keri . thanks for the thoughts. I now have visions of your neighbour taking a Wildcat into their condo, and telling the landlord .Pet? That ain.t no pet . it.s a wild animal!. What you are describing . membership in multiple categories that may or may not be variable / time-based, is of course where IT systems with their typical single-inheritance models break down. The use of state models to describe time-based categories and/or roles is an .implementation detail. of the wider knowledge representation. Cheers Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 08 December 2008 19:48 To: Paul Vincent; SBVR RTF Subject: Re: State <-- SBVR Issue: can a role range over multiple object types Importance: Low Hi, Paul . a couple of thoughts that have continued to cook since you wrote your note. I can see now where some things I wrote could have gotten you (and perhaps Ed) to think of the 'state' aspect of 'role'. Indeed, wearing my Model Systems hat there is the 'life history' view where Fluffy is born as an 'animal' and then (possibly at the same time or perhaps latter) in her life as a 'pet' ... and then maybe dies and is born in (out of and into) her 'pet' life (as she becomes homeless and is then adopted), until she finally dies in her 'animal' life. That is an interesting way to regard and understand 'role' in this non-fact-type-role sense. What I was thinking of in the 'perception' sense was not in this state/over-time sense but rather when from a single point-in-time where Fluffy is a 'pet' (and, of course, simulatenously an 'animal') -- 'regard' rather than 'perceive' might be a better term. From this perspective, there could be a rule that regards Fluffy in her pet-ness . say, our condo rule that says, "No Pets Allowed!" And then Fluffy could (at the same time) be covered in her animal-ness by a rule/policy that says, "Be kind of animals . no animal abuse." In both cases, these are applying to one-and-the-same Fluffy ... but each regards her in a different role/essence sense. ~ Keri On 12/4/08 11:42 AM, "Paul Vincent" wrote: Hi Keri . that.s interesting. Might it be your .perception. that changes state from understanding Fluffy (.s role) as a pet, from just some other annoying animal (role). ? Isn.t .state. in SBVR is just considered another fact type? [Sorry to digress. but at Tibco we use state modeling in our CEP product to help model situations like .changeable roles. . an IT perspective, of course]. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 04 December 2008 20:27 To: Ed Barkmeyer; SBVR RTF Subject: Re: SBVR Issue: can a role range over multiple object types On 12/4/08 10:04 AM, "Ed Barkmeyer" wrote: > There is no formal definition of 'role' here. And SBVR has no notion of > 'steps into'. Keri is talking about a change of state. A world is. A > later world is a different world. SBVR has no temporal concept, no > concept of ordering worlds. So this concept, which relies on those > notions, is out of scope in SBVR v1. But that doesn't mean we have to > discard it. It just means that the formal notions its definition needs > are unavailable. Let me try again. I agree that the "steps into" wording is not SBVR-speak. But the notion I was talking about is not state change. Perhaps if we can get on the same page about the basics of what this non-fact-type-role is about then we can build on that and sort out how 'ranges over' fits in. In Clause 11 we attempted make a basic distinction between 'fundamental' and 'situational' -- concepts where it's part of the 'essence' of a thing to be one of those vs. concepts where its things are perceived to be instances situationally. Kinda hard to say this formally ... "steps into the role" ("plays the role") just seems easier to grasp. This isn't something that the SBVRites made up out of whole cloth. E.g., Sowa talks about 'pet' (role) vs. 'animal' (fundamental). Sorry -- I don't have my Sowa book handy to recall his particular terminology. In any case, Fluffy does not undergo a state change when I perceive her as a pet because of her situation. And whether or not Fluffy is playing that role she is fundamentally . as part of her essence . always an animal (cat). Keri Date: Thu, 19 Mar 2009 14:40:49 +0000 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: "'SBVR RTF'" Subject: [SBVR] Second thoughts on Issue 13135 Hello all, Seeing Ed.s and Mark.s comments about .facet. in discussion of issue 13716 made me think again about Issue 13135. The proposed resolution of 13135 says: .Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types, and that all of the object types are coextensional.. To me, this doesn.t seem to be what people usually mean when they talk about a role ranging over more than one object type. I think that wanting a role to range over both of two coextensional concepts is fairly rare . the examples I can think of seem contrived, e.g. bringing together a country and its head of state. I think people usually mean .union of extensions., and then what.s needed is (some subset of) the intersection of their incorporated characteristics (or something close to this - see below). For example, if you want the role .borrower. (for a loan) to range over company and person, the extension is all the companies and people you are interested in. The incorporated characteristics for the role are characteristics they have in common that are relevant to the role (e.g. name, physical address, credit rating, ownership of asset put up as security, etc), and not those that are different (e.g. company makes product, person has gender). This seems to me to illustrate one of the roles of facet. Company and person each have a facet (.aspect. in my local vocabulary) that can play the role of borrower. At first glance, it appears that this removes the issue, because you would define a new object type, .borrower., so that you can say what characteristics it has. But it removes it by only one step. Properties of borrower are likely to be of two kinds: Properties of company and person that are roles of the same object type, e.g. address (of borrower) ranges over physical address (of company) and physical address (of person) Properties of person and company that are different, but can play the same role for borrower, e.g. legal reference (of borrower) ranges over registration number (of company) and social security number (of person). Regards, John DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MIMEOLE:Thread-Index:In-Reply-To; b=L42pwBZt261ih9q6w8I5/ivKiptM4rDHlXlZwhlcdGVA1jQjAsBEX8wakS/P1HR66MWAIBRxBf1nMjMmYfoW36yd7tRUPBSiClxA3ZNlucsXAZvCZPHB0ZSs2gwfXJvhHCEag3L5L6RLdxynYo1bEbGceftRDQAhzEW1ld0r6qg= ; X-YMail-OSG: bEoKkbwVM1lbRGy_g5JHvT23aT4zttBAGnglpr9.I_dH8Ji7GVBH_j54Qg32mZq9m5m2NG1sfTCpGby0nD0GrlM0ZBUPuDKVmX_jv7FaqTY4aVNoOeCWK2jBZMVSMXcDTF5WIJWgMV83h_VHZsesV8Sq8vRfSMX1wPch6G4A0F6Bu.pF_i_Trcie315iwRu.AccbbedXED5ODojEwAABya4L91pW9IKp X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'SBVR RTF'" Subject: RE: issue 13135 -- SBVR RTF issue Date: Thu, 19 Mar 2009 11:40:13 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmYLfNSMaYXwAQhEd6lcgARJM+CggQee/Pw All, While pondering John.s question to Keri about extensional definitions and multiple .role ranges over object type. fact types for the same role, another problem with the current proposed resolution occurred to me. The way the resolution is currently worded, if you add a new .role ranges over object type. fact type to an existing one for the same role, you actually change the meaning of the first one. That is inconsistent with the rest of SBVR where each fact type has its own meaning that is not changed by the addition of another fact type of the same kind. The attached revision to the Issue 13135 resolution wording addresses this problem. I believe this same problem would need to be taken into account if we change our approach to the one John Hall has recommended. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 26 February 2009 11:19 To: John Hall Cc: Donald R. Chapin; SBVR RTF Subject: Re: issue 13135 -- SBVR RTF issue On 2/25/09 8:50 AM, "John Hall" wrote: I agree that the union has to be defined. But isn't it sufficient to embed the extensional definition in the 'ranges over' fact type? Thanks, John. I am hoping that the answer is something straightforward like that. Keri Date: Thu, 19 Mar 2009 14:40:49 +0000 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: "'SBVR RTF'" Subject: [SBVR] Second thoughts on Issue 13135 Hello all, Seeing Ed.s and Mark.s comments about .facet. in discussion of issue 13716 made me think again about Issue 13135. The proposed resolution of 13135 says: .Saying a role ranges over multiple object types is equivalent to saying the role ranges over a single, possibly anonymous, object type whose incorporated characteristics are the union of those incorporated by the multiple object types, and that all of the object types are coextensional.. To me, this doesn.t seem to be what people usually mean when they talk about a role ranging over more than one object type. I think that wanting a role to range over both of two coextensional concepts is fairly rare . the examples I can think of seem contrived, e.g. bringing together a country and its head of state. I think people usually mean .union of extensions., and then what.s needed is (some subset of) the intersection of their incorporated characteristics (or something close to this - see below). For example, if you want the role .borrower. (for a loan) to range over company and person, the extension is all the companies and people you are interested in. The incorporated characteristics for the role are characteristics they have in common that are relevant to the role (e.g. name, physical address, credit rating, ownership of asset put up as security, etc), and not those that are different (e.g. company makes product, person has gender). This seems to me to illustrate one of the roles of facet. Company and person each have a facet (.aspect. in my local vocabulary) that can play the role of borrower. At first glance, it appears that this removes the issue, because you would define a new object type, .borrower., so that you can say what characteristics it has. But it removes it by only one step. Properties of borrower are likely to be of two kinds: Properties of company and person that are roles of the same object type, e.g. address (of borrower) ranges over physical address (of company) and physical address (of person) Properties of person and company that are different, but can play the same role for borrower, e.g. legal reference (of borrower) ranges over registration number (of company) and social security number (of person). Regards, John From: Don Baisley To: "sbvr-rtf@omg.org" Date: Sat, 28 Mar 2009 21:22:15 -0700 Subject: SBVR Issue 13135 proposed resolution Thread-Topic: SBVR Issue 13135 proposed resolution Thread-Index: AcmwJfBfLJ1ASXU/SqOftYxqQ2+uKg== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US As requested at our recent RTF meeting, I changed the order of the proposed text for to first address the case of a role that can be played by instances of any of a number of types. Then, in contrast, I explain what is meant by a role ranging over multiple object types. I think the new text is easier to grasp because it starts with the more expected case. Regards, Don