Issue 15805: SBVR editorial issue (sbvr-rtf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Problem: In clause 14.3, page 193, the example XML is wrong because it relates roles to the objectTypes ranged over using <sbvr:concept1SpecializesConcept2> instead of <sbvr:roleRangesOverObjectType> as required in the remainder of the specification, as shown in the diagram on page 192, and as shown in the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is an editorial error that remains from when the SBVR FTF created the "role ranges over object type" verb concept. Also, the <sbvr:factType> element should be <sbvr:binaryFactType> and the <sbvr:designation> element should be <sbvr:factSymbol> On page 192, in the diagram, the box labelled ": fact type" should instead be labelled ": binary fact type", and the box labelled ": designation" (the one that is connected to the text box with "value=appoints") should instead be labelled ": fact symbol". Proposed Resolution: Update the diagram on page 192 as follows: - replace the text in the box labelled ": fact type" with the replacement text ": binary fact type: - replace the text in the box labelled ": designation" that is connected to the text box with "value=appoints", with the replacement text ": fact symbol" See this screen shot to identify the boxes that should be updated: Make these changes to the example XML on page 193: <sbvr:factType xmi:id="cao-c" role="cao-r1 cao-r2"/> --> <sbvr:binaryFactType xmi:id="cao-c" role="cao-r1 cao-r2"/> <sbvr:designation xmi:id="appoints" signifier="appoints-t" meaning="cao-c"/> --> <sbvr:factSymbol xmi:id="appoints" signifier="appoints-t" meaning="cao-c"/> <sbvr:concept1SpecializesConcept2 concept1="cao-r1" concept2="company-c"/> --> <sbvr:RangesOverObjectType role="cao-r1" objectType="company-c"/> <sbvr:concept1SpecializesConcept2 concept1="cao-r2" concept2="officer-c"/> --> <sbvr:RangesOverObjectType role="cao-r2" objectType="officer-c"/> Resolution: Revised Text: Actions taken: November 5, 2010: received issue Discussion: End of Annotations:===== ubject: SBVR editorial issue X-KeepSent: 810DAE96:3C5172B9-852577D2:005145E4; type=4; name=$KeepSent To: sbvr-rtf@omg.org, juergen@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Fri, 5 Nov 2010 11:42:37 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 11/05/2010 11:42:41 Problem: In clause 14.3, page 193, the example XML is wrong because it relates roles to the objectTypes ranged over using instead of as required in the remainder of the specification, as shown in the diagram on page 192, and as shown in the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is an editorial error that remains from when the SBVR FTF created the "role ranges over object type" verb concept. Also, the element should be and the element should be On page 192, in the diagram, the box labelled ": fact type" should instead be labelled ": binary fact type", and the box labelled ": designation" (the one that is connected to the text box with "value=appoints") should instead be labelled ": fact symbol". Proposed Resolution: Update the diagram on page 192 as follows: - replace the text in the box labelled ": fact type" with the replacement text ": binary fact type: - replace the text in the box labelled ": designation" that is connected to the text box with "value=appoints", with the replacement text ": fact symbol" See this screen shot to identify the boxes that should be updated: Make these changes to the example XML on page 193: --> --> --> --> -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Date: Fri, 05 Nov 2010 12:43:42 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" , "juergen@omg.org" Subject: Re: SBVR editorial issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: oA5Ghl88026866 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1289580231.86487@/+tLrnuz0fk0y7GXAMg8PA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov I noticed that there are two occurrences of concept1SpecializesConcept2 for the two roles in that example. We could probably correct that incidentally to resolving Issue 15635, especially if we make any changes to the use of starting character position (which is also used in that example). Is it clear that the fact type should be identified as a binary fact type? It is one, but that can be inferred from the fact that it has exactly two roles. And, in a similar way, why 'factSymbol' instead of 'designation'? I see no stated requirement for the use of the narrowest SBVR concept that a given concept instantiates, and I cannot use sbvr:factSymbol if I export using the LogicalFormulationOfSemantics schema, for example. (I think there is some underlying issue here, but it would help if we could figure out what that issue is.) -Ed Mark H Linehan wrote: _Problem:_ In clause 14.3, page 193, the example XML is wrong because it relates roles to the objectTypes ranged over using instead of as required in the remainder of the specification, as shown in the diagram on page 192, and as shown in the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is an editorial error that remains from when the SBVR FTF created the "role ranges over object type" verb concept. Also, the element should be and the element should be On page 192, in the diagram, the box labelled ": fact type" should instead be labelled ": binary fact type", and the box labelled ": designation" (the one that is connected to the text box with "value=appoints") should instead be labelled ": fact symbol". _Proposed Resolution:_ Update the diagram on page 192 as follows: - replace the text in the box labelled ": fact type" with the replacement text ": binary fact type: - replace the text in the box labelled ": designation" that is connected to the text box with "value=appoints", with the replacement text ": fact symbol" See this screen shot to identify the boxes that should be updated: Make these changes to the example XML on page 193: --> --> --> --> -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com -- 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 editorial issue X-KeepSent: BD3307BF:E4E7CE53-852577D2:005DA54F; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Fri, 5 Nov 2010 13:26:05 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 11/05/2010 13:26:07 I see one occurrence of for each role of the example verb concept "company appoints officer". As for "use of the narrowest SBVR concept", I just followed the pattern given in 13.6.4. An advantage of using the narrowest concept is that it clearly identifies the exact concept type in the exchange file. I do think we should say something explicitly about whether producers of SBVR documents should generate "the narrowest SBVR concept" and also whether consumers of SBVR documents should automatically apply SBVR definitions to "narrow" a concept such as "fact type" to "characteristic" or "binary fact type" where appropriate. This issue affects at least the following concepts: * characteristic, binary fact type (these are also "fact type") * fact symbol, term (these are also "designation") * text (which could be transmitted as "expression") Clearly, you have to use the narrower form when it has attributes that need to be represented in the XML file. An example is with its attribute "placeholder uses designation". A placeholder is a kind of designation but you can't communicate "placeholder uses designation" in . There are other cases where a narrower form has significant semantic meaning that you wouldn't want to lose. An example is versus . Regarding "I cannot use sbvr:factSymbol if I export using the LogicalFormulationOfSemantics schema" -- this could be a reason why the burden should be on consumers to "narrow" incoming concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer ---11/05/2010 12:46:00 PM---I noticed that there are two occurrences of concept1SpecializesConcept2 for the two roles in that From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" , "juergen@omg.org" Date: 11/05/2010 12:46 PM Subject: Re: SBVR editorial issue -------------------------------------------------------------------------------- I noticed that there are two occurrences of concept1SpecializesConcept2 for the two roles in that example. We could probably correct that incidentally to resolving Issue 15635, especially if we make any changes to the use of starting character position (which is also used in that example). Is it clear that the fact type should be identified as a binary fact type? It is one, but that can be inferred from the fact that it has exactly two roles. And, in a similar way, why 'factSymbol' instead of 'designation'? I see no stated requirement for the use of the narrowest SBVR concept that a given concept instantiates, and I cannot use sbvr:factSymbol if I export using the LogicalFormulationOfSemantics schema, for example. (I think there is some underlying issue here, but it would help if we could figure out what that issue is.) -Ed Mark H Linehan wrote: > > _Problem:_ > > In clause 14.3, page 193, the example XML is wrong because it relates > roles to the objectTypes ranged over using > instead of > as required in the remainder of the > specification, as shown in the diagram on page 192, and as shown in > the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is > an editorial error that remains from when the SBVR FTF created the > "role ranges over object type" verb concept. > > Also, the element should be and > the element should be > > On page 192, in the diagram, the box labelled ": fact type" should > instead be labelled ": binary fact type", and the box labelled ": > designation" (the one that is connected to the text box with > "value=appoints") should instead be labelled ": fact symbol". > > _Proposed Resolution:_ > > Update the diagram on page 192 as follows: > > - replace the text in the box labelled ": fact type" with the > replacement text ": binary fact type: > - replace the text in the box labelled ": designation" that is > connected to the text box with "value=appoints", with the replacement > text ": fact symbol" > > See this screen shot to identify the boxes that should be updated: > > > Make these changes to the example XML on page 193: > > --> > > meaning="cao-c"/> --> signifier="appoints-t" meaning="cao-c"/> > concept2="company-c"/> --> objectType="company-c"/> > concept2="officer-c"/> --> objectType="officer-c"/> > > > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > phone: (914) 784-7002 or IBM tieline 863-7002 > internet: mlinehan@us.ibm.com > -- 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: Fri, 05 Nov 2010 15:09:23 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: SBVR editorial issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: oA5J9Tk0007595 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1289588971.56927@4RQ9ky+wF2EZgr9Z1/nUPQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark, I think we agree completely. -Ed Mark H Linehan wrote: I see one occurrence of for each role of the example verb concept "company appoints officer". As for "use of the narrowest SBVR concept", I just followed the pattern given in 13.6.4. An advantage of using the narrowest concept is that it clearly identifies the exact concept type in the exchange file. I do think we should say something explicitly about whether producers of SBVR documents should generate "the narrowest SBVR concept" and also whether consumers of SBVR documents should automatically apply SBVR definitions to "narrow" a concept such as "fact type" to "characteristic" or "binary fact type" where appropriate. Yes!! This issue affects at least the following concepts: * characteristic, binary fact type (these are also "fact type") * fact symbol, term (these are also "designation") * text (which could be transmitted as "expression") Clearly, you have to use the narrower form when it has attributes that need to be represented in the XML file. An example is with its attribute "placeholder uses designation". A placeholder is a kind of designation but you can't communicate "placeholder uses designation" in . There are other cases where a narrower form has significant semantic meaning that you wouldn't want to lose. An example is versus . Regarding "I cannot use sbvr:factSymbol if I export using the LogicalFormulationOfSemantics schema" -- this could be a reason why the burden should be on consumers to "narrow" incoming concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Inactive hide details for Ed Barkmeyer ---11/05/2010 12:46:00 PM---I noticed that there are two occurrences of concept1SpecialEd Barkmeyer ---11/05/2010 12:46:00 PM---I noticed that there are two occurrences of concept1SpecializesConcept2 for the two roles in that From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" , "juergen@omg.org" Date: 11/05/2010 12:46 PM Subject: Re: SBVR editorial issue ------------------------------------------------------------------------ I noticed that there are two occurrences of concept1SpecializesConcept2 for the two roles in that example. We could probably correct that incidentally to resolving Issue 15635, especially if we make any changes to the use of starting character position (which is also used in that example). Is it clear that the fact type should be identified as a binary fact type? It is one, but that can be inferred from the fact that it has exactly two roles. And, in a similar way, why 'factSymbol' instead of 'designation'? I see no stated requirement for the use of the narrowest SBVR concept that a given concept instantiates, and I cannot use sbvr:factSymbol if I export using the LogicalFormulationOfSemantics schema, for example. (I think there is some underlying issue here, but it would help if we could figure out what that issue is.) -Ed Mark H Linehan wrote: > > _Problem:_ > > In clause 14.3, page 193, the example XML is wrong because it relates > roles to the objectTypes ranged over using > instead of > as required in the remainder of the > specification, as shown in the diagram on page 192, and as shown in > the "XML Patterns for Fact Types" in clause 13.6.4. I believe this is > an editorial error that remains from when the SBVR FTF created the > "role ranges over object type" verb concept. > > Also, the element should be and > the element should be > > On page 192, in the diagram, the box labelled ": fact type" should > instead be labelled ": binary fact type", and the box labelled ": > designation" (the one that is connected to the text box with > "value=appoints") should instead be labelled ": fact symbol". > > _Proposed Resolution:_ > > Update the diagram on page 192 as follows: > > - replace the text in the box labelled ": fact type" with the > replacement text ": binary fact type: > - replace the text in the box labelled ": designation" that is > connected to the text box with "value=appoints", with the replacement > text ": fact symbol" > > See this screen shot to identify the boxes that should be updated: > > > Make these changes to the example XML on page 193: > > --> > > meaning="cao-c"/> --> signifier="appoints-t" meaning="cao-c"/> > concept2="company-c"/> --> objectType="company-c"/> > concept2="officer-c"/> --> objectType="officer-c"/> > > > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > phone: (914) 784-7002 or IBM tieline 863-7002 > internet: mlinehan@us.ibm.com > -- 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." -- 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: SBVR Issue 15805 - agreed resolution X-KeepSent: C970B4BA:50872968-852577F8:00467CE2; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 13 Dec 2010 07:51:22 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 12/13/2010 08:06:40 X-Content-Scanned: Fidelis XPS MAILER Here is the resolution that we agreed during our recent RTF phone call. Thanks to Don for the revised figure. (See attached file: SBVR Issue 15805.doc) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com SBVR Issue 15805.doc From: Don Baisley To: Mark H Linehan , "sbvr-rtf@omg.org" Subject: RE: SBVR Issue 15805 - agreed resolution Thread-Topic: SBVR Issue 15805 - agreed resolution Thread-Index: AQHLmsb/vtrnl2P06Uqa2sgUfb1nzpOevvbA Date: Mon, 13 Dec 2010 19:19:20 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Mark, There appears to be two places in your proposed resolution where .sbvr:RangesOverObjectType. should be changed to .sbvr:roleRangesOverObjectType.. Otherwise, the resolution looks fine. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 13, 2010 4:51 AM To: sbvr-rtf@omg.org Subject: SBVR Issue 15805 - agreed resolution Here is the resolution that we agreed during our recent RTF phone call. Thanks to Don for the revised figure. (See attached file: SBVR Issue 15805.doc) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Subject: RE: SBVR Issue 15805 - agreed resolution X-KeepSent: B0972B10:E9923143-852577F8:006D6114; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 13 Dec 2010 14:55:25 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 12/13/2010 14:55:30 X-Content-Scanned: Fidelis XPS MAILER Ah, thanks for spotting that. Here's an updated version: (See attached file: SBVR Issue 15805v2.doc) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---12/13/2010 02:22:20 PM---Mark, There appears to be two places in your proposed resolution where "sbvr:RangesOverObjectType" s From: Don Baisley To: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 12/13/2010 02:22 PM Subject: RE: SBVR Issue 15805 - agreed resolution -------------------------------------------------------------------------------- Mark, There appears to be two places in your proposed resolution where âsbvr:RangesOverObjectTypeâ should be changed to âsbvr:roleRangesOverObjectTypeâ. Otherwise, the resolution looks fine. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, December 13, 2010 4:51 AM To: sbvr-rtf@omg.org Subject: SBVR Issue 15805 - agreed resolution Here is the resolution that we agreed during our recent RTF phone call. Thanks to Don for the revised figure. (See attached file: SBVR Issue 15805.doc) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com SBVR Issue 15805v2.doc