Issue 16719: Date Time Issue - compound quantity value cardinality mismatch (date-time-ftf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: A Necessity under "compound quantity value has atomic quantity value" in Annex D.2.3 says: Necessity: Each compound quantity value has at least two atomic quantity values. I believe this is correct. Problem: the UML diagram in figure 79 at the start of Annex D.2.3 shows cardinality "1..*" at the "atomic quantity value" end of the corresponding association. Resolution: Revised Text: Actions taken: November 18, 2011: received issue Discussion: End of Annotations:===== MG Issue No: 16719 Title: Compound Quantity Value Cardinality Mismatch Source: Mark H. Linehan . IBM . mlinehan@us.ibm.com Summary: A Necessity under "compound quantity value has atomic quantity value" in Annex D.2.3 says: Necessity: Each compound quantity value has at least two atomic quantity values. I believe this is correct. Problem: the UML diagram in figure 79 at the start of Annex D.2.3 shows cardinality "1..*" at the "atomic quantity value" end of the corresponding association. Date: Thu, 19 Jul 2012 19:28:37 -0400 From: Ed Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: OMG DateTimeVoc FTF Subject: DTV Issues: 16719 and 17129 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q6JNSgn4007336 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1343345324.32532@ywM3HWX8kCQg4vSP1oPomQ X-Spam-Status: No I attach draft resolutions to: - DTV Issue 16719 - compound quantity value cardinality mismatch. Changes only the UML diagram. - DTV Issue 17129 - specify the UML Profile for SBVR that contains the stereotypes used in the UML diagrams. The resolution provides the text of a new Annex (J) and modifies the text of 5.2 to introduce it and the stereotypes it defines. Note: There are two known concerns about 17129: - It has been suggested that this Annex should be part of a proper normative Annex to SBVR. If that should ever happen, Annex J can be removed by a later RTF, and appropriate changes made to 5.2 to reference the SBVR specification. - Several other outstanding issues contain text changes for section 5, possibly in 5.2. We will need to coordinate those changes with the changes in 17129. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 DTV Issue 17129 - Define the UML Profile for SBVR.docx DTV Issue 16719 - compound quantity value cardinality mismatch.doc Disposition: Resolved OMG Issue No: 16719 Title: Compound Quantity Value Cardinality Mismatch Source: Mark H. Linehan . IBM . mlinehan@us.ibm.com Summary: A Necessity under "compound quantity value has atomic quantity value" in Annex D.2.3 says: Necessity: Each compound quantity value has at least two atomic quantity values. I believe this is correct. Problem: the UML diagram in figure 79 at the start of Annex D.2.3 shows cardinality "1..*" at the "atomic quantity value" end of the corresponding association. Resolution: Accepted. The UML diagram will be changed. Other minor improvements are also made to the diagram. Revised Text: In clause D.3.3, REPLACE Figure D.7 with: Disposition: Resolved To: date-time-ftf@omg.org Subject: Re: DTV Issues: 16719 and 17129 X-KeepSent: 7593D0D9:0D66AB45-85257A47:00103812; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Wed, 25 Jul 2012 23:36:55 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 07/25/2012 23:36:56, Serialize complete at 07/25/2012 23:36:56 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072603-5930-0000-0000-00000A378E55 Regarding 16719: * Looks good to me. Regarding 17129: * In clause 5, while you're at it, I suggest updating the term "fact symbol" in the 5th bullet, and the terms "fact type" and "fact type role" in the 7th bullet. * You should also delete table 5.1 (plus the introductory text) since you now document these stereotypes in the new Annex. * I found the second sentence of paragraph of J.2.1 confusing: "A categorization type is similar to a UML Powertype, whose instances are all the subclasses of a given Class. All the subclasses of a given Class, however, are not necessarily mutually exclusive. The extension of a categorization type is a particular set of subclasses that are mutually exclusive. " I think you are saying that in a Powertype, the second sentence applies but not in a categorization type. Please clarify. * In J.2.2, the word "is" is extraneous in the sentence âCategorization type X is categorizes concept Y.â * In J.3, I would drop the sentence "All of the verb concepts in this specification can be understood to represent states." Maybe this statement is true now, but it may become false as the specification evolves. The profile may be used for other purposes where this statement is not true. And the statement does not add any real value. * In J.3, I think "verb concept roles" should be fully styled. That is, the 's' should be treated like the rest of the term. * I don't understand this statement in J.3: "The problem is that the meaning of the multiplicities in an N-ary Association cannot be easily related to states, and the number of such states in which a given instance of a participating class participates cannot be documented as a multiplicity." Each instance of a verb concept has 1 thing participating in each role. So the N-ary association should show a multiplicity of 1 at the far end of each of the associations and a multiplicity of * at the near end. * I think that the alternative in J.3 to reificiation would be association classes, not n-ary assocations. An association class has its own state, whereas an association has no independent state. For example, an employment -- the reification of employs -- has state that includes at least the two roles and but potentially also , , etc. I think the reason we don't use association classes is because of poor tool support. -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: OMG DateTimeVoc FTF , Date: 07/19/2012 07:29 PM Subject: DTV Issues: 16719 and 17129 -------------------------------------------------------------------------------- I attach draft resolutions to: - DTV Issue 16719 - compound quantity value cardinality mismatch. Changes only the UML diagram. - DTV Issue 17129 - specify the UML Profile for SBVR that contains the stereotypes used in the UML diagrams. The resolution provides the text of a new Annex (J) and modifies the text of 5.2 to introduce it and the stereotypes it defines. Note: There are two known concerns about 17129: - It has been suggested that this Annex should be part of a proper normative Annex to SBVR. If that should ever happen, Annex J can be removed by a later RTF, and appropriate changes made to 5.2 to reference the SBVR specification. - Several other outstanding issues contain text changes for section 5, possibly in 5.2. We will need to coordinate those changes with the changes in 17129. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 [attachment "DTV Issue 17129 - Define the UML Profile for SBVR.docx" deleted by Mark H Linehan/Watson/IBM] [attachment "DTV Issue 16719 - compound quantity value cardinality mismatch.doc" deleted by Mark H Linehan/Watson/IBM] Date: Thu, 26 Jul 2012 14:15:31 -0400 From: Ed Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "date-time-ftf@omg.org" Subject: Re: DTV Issues: 16719 and 17129 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q6QIFbEw025074 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1343931344.78223@NYnkJdWbh1/FAoZIQN3gbQ X-Spam-Status: No Mark H Linehan wrote: Regarding 16719: * Looks good to me. Regarding 17129: * In clause 5, while you're at it, I suggest updating the term "fact symbol" in the 5th bullet, and the terms "fact type" and "fact type role" in the 7th bullet. * You should also delete table 5.1 (plus the introductory text) since you now document these stereotypes in the new Annex. ok. * I found the second sentence of paragraph of J.2.1 confusing: "A categorization type is similar to a UML Powertype, whose instances are all the subclasses of a given Class. All the subclasses of a given Class, however, are not necessarily mutually exclusive. The extension of a categorization type is a particular set of subclasses that are mutually exclusive. " I think you are saying that in a Powertype, the second sentence applies but not in a categorization type. Please clarify. OK. What is meant is that the extension of a Powertype is the set of all subclasses of the given Class. Those are not necessarily all mutually exclusive. The extension of a categorization type is some set of subclasses that are mutually exclusive. SBVR explicitly says that the set is not necessarily 'complete'. * In J.2.2, the word "is" is extraneous in the sentence .Categorization type X is categorizes concept Y.. * In J.3, I would drop the sentence "All of the verb concepts in this specification can be understood to represent states." Maybe this statement is true now, but it may become false as the specification evolves. The profile may be used for other purposes where this statement is not true. And the statement does not add any real value. * In J.3, I think "verb concept roles" should be fully styled. That is, the 's' should be treated like the rest of the term. * I don't understand this statement in J.3: "The problem is that the meaning of the multiplicities in an N-ary Association cannot be easily related to states, and the number of such states in which a given instance of a participating class participates cannot be documented as a multiplicity." Each instance of a verb concept has 1 thing participating in each role. So the N-ary association should show a multiplicity of 1 at the far end of each of the associations and a multiplicity of * at the near end. The problem with all this terminology is to agree on what to call the instances of a verb concept. If we are pleased to call them 'actualities' rather than 'links' or 'states', then substitute 'actuality' for 'state' and the text should make sense. Each instance of a class stereotyped 'verb concept' is an actuality in which each role is played exactly once. A given instance of the range class may have some rule for the number of such actualities it can participate in, in the same way the UML model attaches a multiplicity to the 'domain' end of a binary association in which it is the 'range'. The problem with mulitiplicites on n-ary associations is this: Consider R(A, B, C). The multiplicity on association end C is said to be the number of C's such that R(A,B,C) holds for a given pair (a, b). If we want to say instead that any given C participates in exactly one actuality of R, i.e., how many times a thing can play the role C, we can't. In our model, the multiplicities on the verb concept end of a verb concept role association represent the cardinality of participation. Of course, that is in a sense just the inverse -- the number of (a,b) pairs that can be associated with a C. But we are counting instances of R, not instances of (a,b), and that becomes much clearer when the relationship has 4 or more roles, and the UML technique only allows you to model the relationship between triples and the remaining role. * I think that the alternative in J.3 to reificiation would be association classes, not n-ary assocations. An association class has its own state, whereas an association has no independent state. For example, an employment -- the reification of employs -- has state that includes at least the two roles and but potentially also , , etc. I think the reason we don't use association classes is because of poor tool support. Association classes are apparently defined to be binary associations, but that may just be another manifestation of poor tool support. If they were n-ary, we would have used them. There is no requirement for any class to have attributes. The idea that associations don't have independent state is OO-think. If it were true, all of the SBVR associations that connote no property of either participating class (have no navigable ends) would have no state at all. But in a RDB, the state is a row in a table representing the association. The relationship does not have to be part of the state model of any participant. And that goes directly to the SBVR idea that verb concepts are first class concepts, and their instances are things in their own right. -Ed -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: OMG DateTimeVoc FTF , Date: 07/19/2012 07:29 PM Subject: DTV Issues: 16719 and 17129 -------------------------------------------------------------------------------- I attach draft resolutions to: - DTV Issue 16719 - compound quantity value cardinality mismatch. Changes only the UML diagram. - DTV Issue 17129 - specify the UML Profile for SBVR that contains the stereotypes used in the UML diagrams. The resolution provides the text of a new Annex (J) and modifies the text of 5.2 to introduce it and the stereotypes it defines. Note: There are two known concerns about 17129: - It has been suggested that this Annex should be part of a proper normative Annex to SBVR. If that should ever happen, Annex J can be removed by a later RTF, and appropriate changes made to 5.2 to reference the SBVR specification. - Several other outstanding issues contain text changes for section 5, possibly in 5.2. We will need to coordinate those changes with the changes in 17129. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 [attachment "DTV Issue 17129 - Define the UML Profile for SBVR.docx" deleted by Mark H Linehan/Watson/IBM] [attachment "DTV Issue 16719 - compound quantity value cardinality mismatch.doc" deleted by Mark H Linehan/Watson/IBM]