Issue 17129: Need Profile for UML Stereotypes (date-time-ftf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile. Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match. Resolution: Revised Text: Actions taken: February 13, 2012: received issue Discussion: End of Annotations:===== MG Issue No: 17129 Title: Need Profile for UML Stereotypes Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile. Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match. Resolution: Date: Thu, 15 Mar 2012 13:39:14 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: OMG DateTimeVoc FTF CC: SBVR RTF Subject: DTV Issue 17129 - formalize the UML Profile (for SBVR concepts) that is used in DTV X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q2FHdKsG010258 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1332437965.2344@AVD8/wCWMfGs6EGACb7ADw X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov All, In a recent DTV telecon, we agreed that this issue should be addressed, but Markus Schacher raised the concern that it should really be addressed in SBVR, because it should reasonably apply to other uses of SBVR. There are two problems here: (1) DTV was to produce a useful SBVR vocabulary and a useful UML model. The UML model is not a model of the SBVR vocabulary. It is a model of the same concept set, using the capabilities of the UML language as well as possible. Since UML is more restrictive and differently expressive than SBVR, a UML model of an SBVR vocabulary for the domain and a UML model of the domain are different ideas. (2) SBVR Annex H already provides a sketch (not a Profile) of the use of UML for capturing some of the intent of SBVR vocabularies. But, Annex H is misleading in its depiction of the use of UML. That is, it describes incomplete and innaccurate uses of UML in representing concepts. The UML interpretation of the diagrams as proposed is not, in many cases, the SBVR intepretation stated in the text of Annex H. It is clear that I should raise an issue about the low quality of Annex H in SBVR, but that still leaves two open questions: 1) is creating a formal UML Profile for SBVR within scope for the SBVR RTF? 2) to what extent is a formal UML Profile for SBVR (generally) needed/useful for the DTV UML models? Much of the DTV use of UML follows the practices defined in SBVR clause 13 or Annex H, but those don't require a formal "profile" -- they add nothing to the UML language. DTV uses the stereotype <> for classes that represent SBVR concept types. UML does not really have the idea of a class (noun concept) whose instances are classes. (UML:Powertype is a special case -- a class whose instances are the modeled subclasses of another class.) In lieu of the N-ary relationship symbol (diamond) recommended in Annex H, we used a UML class stereotyped <> (now <>), and we used associations stereotyped <> to link the roles to the verb concept (class). The primary reason for this is to specify participation multiplicities. That is the extent of the DTV "Profile" for UML. A formal UML Profile for SBVR would presumably include other markups suggested in Annex H. It seems to me that DTV v1.0 should simply contain a formal UML Profile that includes exactly the three stereotypes it uses and no others. And it should say this is not a UML Profile for SBVR, and that it may be replaced by a UML Profile for SBVR in some future version. If the SBVR RTF undertakes to create a UML Profile for SBVR, then the two specifications can be aligned in a future version. One alternative is to use the UML n-ary relationship symbol recommended in Annex H, state all the multiplicities as 0..*, and then specify the real participation cardinalities in separate OCL rules. This would leave only the <> stereotype, which could be removed from the diagrams. But Markus' alternative -- that we should have and use a UML Profile for SBVR -- needs to be discussed. We need clear guidance. -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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-15_04:2012-03-15,2012-03-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203150188 Subject: Re: DTV Issue 17129 - formalize the UML Profile (for SBVR concepts) that is used in DTV From: keri Date: Thu, 15 Mar 2012 08:56:42 -1000 Cc: SBVR RTF , OMG DateTimeVoc FTF To: edbark@nist.gov X-Mailer: Apple Mail (2.1084) On Mar 15, 2012, at 7:39 AM, Ed Barkmeyer wrote: > It is clear that I should raise an issue about the low quality of Annex H in SBVR, but that still leaves two open questions: > 1) is creating a formal UML Profile for SBVR within scope for the SBVR RTF? 2) to what extent is a formal UML Profile for SBVR (generally) needed/useful for the DTV UML models? Ed, At the last SBVR telcon, one Annex H fix was identified (H.4.3), along with correcting the various Figure diagrams in Clause 11 that reflect differing/conflicting styles for this element. I agreed to log an issue for this but if there are more problems in Annex H (suggesting additional 'tweaks' to Figure diagrams) then I would prefer to have the broader "get Annex H right" discussion occur as one coherent unit of work. I will hold off logging the narrow issue and defer its fixes to your broader item. I don't know what is involved in developing a Profile but it sounds like that could extend the discussion beyond getting Annex H improved and the Figure diagrams consistent. If that is the case then my preference would be to approach this in two steps: get Annex H in good shape and then use that as a foundation for Profile work. ~ Keri Date: Thu, 15 Mar 2012 16:58:19 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: SBVR RTF , OMG DateTimeVoc FTF Subject: Re: DTV Issue 17129 - formalize the UML Profile (for SBVR concepts) that is used in DTV X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov keri wrote: On Mar 15, 2012, at 7:39 AM, Ed Barkmeyer wrote: It is clear that I should raise an issue about the low quality of Annex H in SBVR, but that still leaves two open questions: 1) is creating a formal UML Profile for SBVR within scope for the SBVR RTF? 2) to what extent is a formal UML Profile for SBVR (generally) needed/useful for the DTV UML models? Ed, At the last SBVR telcon, one Annex H fix was identified (H.4.3), along with correcting the various Figure diagrams in Clause 11 that reflect differing/conflicting styles for this element. I agreed to log an issue for this but if there are more problems in Annex H (suggesting additional 'tweaks' to Figure diagrams) then I would prefer to have the broader "get Annex H right" discussion occur as one coherent unit of work. I will hold off logging the narrow issue and defer its fixes to your broader item. I don't know what is involved in developing a Profile but it sounds like that could extend the discussion beyond getting Annex H improved and the Figure diagrams consistent. If that is the case then my preference would be to approach this in two steps: get Annex H in good shape and then use that as a foundation for Profile work. Well, the usual concern in UML Profiles is to specify the possible stereotypes and their meanings, and any attached model element properties that are not standard UML properties. For example, in H.4.2, there is an <> stereotype on a Generalization. In UML v2.2ff, that can only be used if the <> stereotype is defined in a Profile. In H.6.2, there is a :modality modifier on a Generalization. In UML terms that is a TagValue, and the Tag (a term that should have preceded the colon) must be defined in a Profile. In H.8, there is a meaningless dashed line between 'car recovery' and a ternary verb concept. It is said to represent 'objectification'. In UML that dashed line should be a Dependency that has a stereotype indicating the nature of that relationship, e.g., <>, defined in a Profile. But there are several other constructs in Annex H that are simply not valid UML or don't mean what the text says. The most notable is the misstatement in H.9 that the default multiplicity is 0..*. The default multiplicity on a UML association end is 1..1, i.e., exactly one. That is why not specifying multiplicity on a UML diagram usually produces a model whose UML interpretation is not what you meant. (Yes, defaulting to multiplicity 1 -- a strong constraint -- was a bad conceptual choice, but when you think primarily in terms of software development, it is a lot harder to represent a relationship that is to a list of things. The idea that one might want to model a semantic network with UML is still foreign to a lot of UML toolsmiths.) One possible solution is to stereotype all SBVR 'association ends' and have the stereotype apply the 'no value' rule to lower-bound and upper-bound, saying that the multiplicities are specified by rules (Necessities). The easier solution is to be less lazy in creating our UML diagrams. Annex H is just another SBVR flirt with language definition. UML provides a formal means. -Ed ~ Keri -- 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-15_04:2012-03-15,2012-03-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203150265 Subject: Re: DTV Issue 17129 - formalize the UML Profile (for SBVR concepts) that is used in DTV From: keri Date: Thu, 15 Mar 2012 13:31:07 -1000 Cc: SBVR RTF , OMG DateTimeVoc FTF To: edbark@nist.gov X-Mailer: Apple Mail (2.1084) On Mar 15, 2012, at 10:58 AM, Edward Barkmeyer wrote: > But there are several other constructs in Annex H that are simply not valid UML or don't mean what the text says. The most notable is the misstatement in H.9 that the default multiplicity is 0..*. The default multiplicity on a UML association end is 1..1, i.e., exactly one. Hmmm... Is this a change in UML 2? Back in the day (late '90s), when we were doing the IDEF1x work (IEEE), we were told that UML used the interpretation that if there is no constraint then the unconstrained state applies -- i.e., for an association, that would be many-to-many. Was that a wrong understanding, even back then? ~ Keri Date: Fri, 16 Mar 2012 12:16:23 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: SBVR RTF , OMG DateTimeVoc FTF Subject: Re: DTV Issue 17129 - formalize the UML Profile (for SBVR concepts) that is used in DTV X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov keri wrote: On Mar 15, 2012, at 10:58 AM, Edward Barkmeyer wrote: But there are several other constructs in Annex H that are simply not valid UML or don't mean what the text says. The most notable is the misstatement in H.9 that the default multiplicity is 0..*. The default multiplicity on a UML association end is 1..1, i.e., exactly one. Hmmm... Is this a change in UML 2? Back in the day (late '90s), when we were doing the IDEF1x work (IEEE), we were told that UML used the interpretation that if there is no constraint then the unconstrained state applies -- i.e., for an association, that would be many-to-many. Was that a wrong understanding, even back then? Well, coming from the NIAM/ORM community in the late 1990s, I was unpleasantly surprised that UML defaulted to 1..1 -- defaulting to a constraint is a poor idea in a modeling language -- but I wrote it off to 'object-headedness'. There were a lot of lies told about UML v1, partly because (a) the UML v1 specification was inconsistent and ambiguous about some of its constructs; and (b) the effective standard was whatever your tool did. Apart from the market dominance by Rational Rose (which did not always conform to the standard), there were a number of other tools, each with its own dialect. Rose2000 defaulted to 1..1; other tools did not. At least one UML v1.4 tool diagnosed 'no specified multiplicity' if you asked it to 'validate' your UML model. I'm pretty sure the 1..1 default was in UML 1.4; I wouldn't want to bet that it was clearly in UML 1.0. But the UML v2.0 Infrastructure model says the default value of Multiplicity.lower_bound and .upper_bound is 1, and that hasn't changed. UML v2.4 provides the following specification for Multiplicity: Attributes ... . lower : Integer [0..1] Specifies the lower bound of the multiplicity interval (Default is one). . upper : UnlimitedNatural [0..1] Specifies the upper bound of the multiplicity interval (Default is one). ... Constraints These constraints must handle situations where the upper bound may be specified by an expression not computable in the model. In this package [UML Infrastructure] such situations cannot arise but they can in subclasses. [1] The lower bound must be a non-negative integer literal. lowerBound()->notEmpty() implies lowerBound() >= 0 [2] The upper bound must be greater than or equal to the lower bound. (upperBound()->notEmpty() and lowerBound()->notEmpty()) implies upperBound() >= lowerBound() There is further discussion of how multiplicity is specified on a diagram. Every UML:Property has a multiplicity, however it is specified. The above text says the 'default' -- the value that is assumed if there is /no specification/ -- is 1. So SBVR H.9 is wrong. What has changed is the discussion of 'how a multiplicity is specified'. 'No specification' does not necessarily mean 'no specification on a diagram'. But you have to provide some clue that you are overriding UML diagram semantics. It is possible that multiplicities are specified by some other means than constants on the diagram, such as a constraint/rule. This is the intent in SBVR, but at the very least SBVR must make clear that its use of UML specifies no multiplicities on the diagrams and /always/ specifies the multiplicities by a rule. But that would mean that, when there is no Necessity that limits the multiplicities, SBVR would have to state the Possibility that there are 0 or more instances. Conforming UML tools seem to support the idea of 'no specified multiplicity', which is doubtless intended to support such approaches. But you can't define a new 'default' to avoid stating the Possibility, because then you are redefining 'not specified', as opposed to 'not specified on the diagram'. The UML Infrastructure supports the idea that a modeler may have some other means of specifying multiplicity, but explicitly for a /specialization/ of a UML concept. It is my impression that SBVR would have to specify that interpretation by explicitly creating a new kind of Association (e.g., via stereotype) or a new kind of Property, for which it defines the means of specifying the multiplicity and overrides the UML diagram semantics for 'not provided'. Such UML extensions, however, are not permitted in the MOF itself. The UML diagrams of the MOF metamodel of SBVR have UML diagram semantics -- no stated mulitiplicity defaults to 1..1. That is the problem. I will admit that I could be wrong about this. The specification is only clear as far as it goes. The proper resolution of this issue should involve a real UML expert. But Annex H makes it clear that no such expert ever participated in SBVR. (You also have to realize that a lot of this stuff got modified after the adoption of the SBVR submission, when several would-be implementors asked the FTF to redesign the MOF metamodel of SBVR to look more like a modeling language. The original SBVR metamodel was nothing more than 'predicate has arguments' where 'argument' is a role of 'thing', and all the UML diagrams were informative drawings.) -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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." 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: 17129 Title: Need Profile for UML Stereotypes Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile. Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match. Resolution: The FTF agrees that there should be a formal UML profile for the stereotypes in the DTV specification. The FTF believes that it is in the best interest of SBVR users and developers that a UML Profile for SBVR be developed by the OMG as an extension to SBVR. In the interim, the FTF agrees to document the profile used in DTV in a DTV annex. Revised Text: 1. In clause 5.2, at the end of the 3rd paragraph (immediately before the bullet list), ADD a sentence: Some SBVR vocabulary items are modeled in the UML model using stereotypes. The stereotypes are formally specified in the UML Profile for SBVR in Annex J. 2. In clause 5.2, in the bullet list, REPLACE the bullet: . Each SBVR object type maps to a UML class. with three bullets: . Each SBVR general concept maps to a UML class. . Each SBVR concept type maps to a UML class with the stereotype «concept type». Where specific concepts that are instances of a concept type are also modeled, the fact that each such a concept is an instance of the concept type is modeled by a UML dependency with the stereotype «instance». . Each SBVR categorization type maps to a UML class with the stereotype «categorization type». The relationship between the categorization type and the general concept it categorizes is modeled by a UML dependency with the stereotype «categorization». 3. In clause 5.2, in the bullet list, in the bullet beginning: . Verb concepts with more than two roles map to UML classes stereotyped as <> REPLACE both occurrences of <> with «verb concept». 4. In clause 5.2, in the bullet list, in the bullet beginning: . SBVR roles map to UML property names , . REPLACE <> with «verb concept role». 5. CREATE a new Annex (tentatively designated Annex J) as follows: Annex J UML Profile for SBVR (normative) This annex specifies the stereotypes that are used to mark up UML model elements in the DTV specification. A general UML Profile for SBVR concepts has not been developed by the OMG. It is expected that such a profile will be developed in the future. At such time, this Annex and the corresponding UML stereotypes in the DTV UML model will be superseded. The UML stereotypes used in this specification are depicted in Figure J-1 and described in detail below. Figure J-1: UML Profile for SBVR The UML metaclass Class is depicted in the diagram because it plays roles in stereotyped relationships. The UML metaclasses Association and Dependency are not depicted. They serve only as the UML base elements for some of the defined stereotypes. J.1 Concept types The SBVR term concept type refers to a concept whose instances are concepts. Two stereotypes are introduced to support this notion. J.1.1 Stereotype «concept type» The stereotype «concept type» characterizes a UML Class as an SBVR concept type. In UML terms, it is a classifier whose instances are classes. J.1.2 Stereotype «instance» The stereotype «instance» characterizes a UML Dependency as representing the relationship between a UML Class (representing an SBVR concept) and a concept type that corresponds to it. That is, the Dependency can be read .Class X is an instance of concept type Y.. The relationship of the «instance» Dependency to the (client) Class that is the instance is represented in the «instance» element by the Tag .instance.. The relationship of the «instance» Dependency to the (supplier) Class that is the concept type is represented in the «instance» element with the Tag .type.. J.2 Categorization types The SBVR term categorization type refers to a concept type whose instances are mutually exclusive subtypes of a common base concept. Two stereotypes are introduced to support this notion. J.2.1 Stereotype «categorization type» The stereotype «categorization type» characterizes a UML Class as an SBVR categorization type. 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. Each categorization type has a «categorization» Dependency on a 'base class' that is the "common base concept" of the instances. J.2.2 Stereotype «categorization» The stereotype «categorization» characterizes a UML Dependency as representing the relationship between a categorization type and the base concept that it categorizes. The base concept is represented by a UML Class (representing an SBVR concept). That is, the Dependency can be read .Categorization type X is categorizes concept Y.. The relationship of the «categorization» Dependency to the (client) categorization type is represented in the «categorization» element by the Tag .type.. The ownership of that dependency is represented in the «categorization type» element by the Tag .categorization.. The relationship of the «categorization» Dependency to the (supplier) Class that is the base concept is represented in the «categorization» element with the Tag .base concept.. J.3 Verb Concepts The SBVR term verb concept refers to a concept whose instances are states or events. All of the verb concepts in this specification can be understood to represent states. A verb concept is said to have verb concept roles that characterize the participation of individual objects in those states. States that involve only one or two participant objects can be represented in UML via Attributes and binary Associations. In theory, a state involving more than two participants can be represented in UML by an N-ary Association. 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. For this reason, this specification represents a verb concept with 3 or more participating verb concept roles as a class with a «verb concept» stereotype, which is conceptually similar to the (now deprecated) UML Association Class. Two stereotypes are introduced to support this approach. J.3.1 Stereotype «verb concept» The stereotype «verb concept» characterizes a UML Class as an SBVR verb concept. In UML terms, it is a classifier whose instances are states. Each «verb concept» Class has one «verb concept role» Association for each verb concept role in the SBVR verb concept that it represents. The set of «verb concept role» Associations for the verb concept are represented in the «verb concept» element by the Tag .roles.. The number of verb concept roles for the verb concept is represented in the «verb concept» element by the Tag .arity.. J.3.2 Stereotype «verb concept role» The stereotype «verb concept role» characterizes a UML Association as representing one verb concept role in an SBVR verb concept that is represented by a «verb concept» Class. Each «verb concept role» Association represents exactly one verb concept role in exactly one SBVR verb concept. Each link that instantiates that Association can be read: In the state (object) X that is the instance of the verb concept Class, the role Y is played by Z, where Y is the association end name on the Association, and Z is the object in the range Class. One end of the «verb concept role» Association is the «verb concept» Class that represents the verb concept. The other end of the Association is the UML Class that represents the range of the verb concept role. The name of that association end is the placeholder for the verb concept role in the verb concept form. In a «verb concept role» Association only the association end that refers to the range of the role is navigable, and it always has multiplicity one, because each verb concept role is played exactly once in any one instance of the verb concept. The relationship of the «verb concept role» Association to the «verb concept» Class is represented in the «verb concept role» element by the Tag .verb concept.. 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] Date: Tue, 31 Jul 2012 19:00:46 -0400 From: Ed Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "date-time-ftf@omg.org" Subject: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q6VN0nkS023084 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1344380451.28629@ZISJDlWnhn7FfZp4mzKMJg X-Spam-Status: No I attach a new draft of the resolution to DTV Issue 17129, addressing all the points in the email discussion of last week (below). -Ed Ed Barkmeyer wrote: Mark H Linehan wrote: 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] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." DTV Issue 17129 - Define the UML Profile for SBVR-d2.docx Disposition: Resolved OMG Issue No: 17129 Title: Need Profile for UML Stereotypes Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile. Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match. Resolution: The FTF agrees that there should be a formal UML profile for the stereotypes in the DTV specification. The FTF believes that it is in the best interest of SBVR users and developers that a UML Profile for SBVR be developed by the OMG as an extension to SBVR. In the interim, the FTF agrees to document the profile used in DTV in a DTV annex. Revised Text: 1. In clause 5.2, at the end of the 3rd paragraph (immediately before the bullet list), ADD a sentence: Some SBVR vocabulary items are modeled in the UML model using stereotypes. The stereotypes are formally specified in the UML Profile for SBVR in Annex J. 2. In clause 5.2, in the bullet list, REPLACE the bullet: . Each SBVR object type maps to a UML class. with three bullets: . Each SBVR general concept maps to a UML class. . Each SBVR concept type maps to a UML class with the stereotype «concept type». Where specific concepts that are instances of a concept type are also modeled, the fact that each such a concept is an instance of the concept type is modeled by a UML dependency with the stereotype «instance». . Each SBVR categorization type maps to a UML class with the stereotype «categorization type». The relationship between the categorization type and the general concept it categorizes is modeled by a UML dependency with the stereotype «categorization». 3. In clause 5.2, in the bullet list, in the bullet: . Each SBVR verb concept that uses the fact symbol has maps to a UML property. CHANGE .fact symbol. to .verb symbol.. 34. In clause 5.2, in the bullet list, in the bullet beginning: . Verb concepts with more than two roles map to UML classes stereotyped as <> CHANGE both occurrences of <> to «verb concept», and in the paragraph below the bullet, CHANGE all four occurrences of .fact type. to .verb concept.. 45. In clause 5.2, in the bullet list, in the bullet beginning: . SBVR roles map to UML property names , . REPLACE <> with «verb concept role». 6. In clause 5.2 DELETE Table 5.1 UML Stereotypes entirely, and DELETE the preceding sentence: Several stereotypes are employed to relate UML model elements to SBVR concepts: 57. CREATE a new Annex (tentatively designated Annex J) as follows: Annex J UML Profile for SBVR (normative) This annex specifies the stereotypes that are used to mark up UML model elements in the DTV specification. A general UML Profile for SBVR concepts has not been developed by the OMG. It is expected that such a profile will be developed in the future. At such time, this Annex and the corresponding UML stereotypes in the DTV UML model will be superseded. The UML stereotypes used in this specification are depicted in Figure J-1 and described in detail below. Figure J-1: UML Profile for SBVR The UML metaclass Class is depicted in the diagram because it plays roles in stereotyped relationships. The UML metaclasses Association and Dependency are not depicted. They serve only as the UML base elements for some of the defined stereotypes. J.1 Concept types The SBVR term concept type refers to a concept whose instances are concepts. Two stereotypes are introduced to support this notion. J.1.1 Stereotype «concept type» The stereotype «concept type» characterizes a UML Class as an SBVR concept type. In UML terms, it is a classifier whose instances are classes. J.1.2 Stereotype «instance» The stereotype «instance» characterizes a UML Dependency as representing the relationship between a UML Class (representing an SBVR concept) and a concept type that corresponds to it. That is, the Dependency can be read .Class X is an instance of concept type Y.. The relationship of the «instance» Dependency to the (client) Class that is the instance is represented in the «instance» element by the Tag .instance.. The relationship of the «instance» Dependency to the (supplier) Class that is the concept type is represented in the «instance» element with the Tag .type.. J.2 Categorization types The SBVR term categorization type refers to a concept type whose instances are mutually exclusive subtypes of a common base concept. Two stereotypes are introduced to support this notion. J.2.1 Stereotype «categorization type» The stereotype «categorization type» characterizes a UML Class as an SBVR categorization type. A categorization type is similar to a UML Powertype., whose The instances of a Powertype are all the subclasses of a given Class. All the subclasses of a given Class, however, are not necessarily mutually exclusive. By comparison, the extension of a categorization type is a particular set of subclasses of a given Class that are mutually exclusive. Only in some cases is the extension of a UML Powertype a set of subclasses that are mutually exclusive, partly because the Powertype necessarily includes all of the subclasses of the categorized Class. Each categorization type has a «categorization» Dependency on a 'base class' that is the "common base concept" of the instances. J.2.2 Stereotype «categorization» The stereotype «categorization» characterizes a UML Dependency as representing the relationship between a categorization type and the base concept that it categorizes. The base concept is represented by a UML Class (representing an SBVR concept). That is, the Dependency can be read .Categorization type X is categorizes concept Y.. The relationship of the «categorization» Dependency to the (client) categorization type is represented in the «categorization» element by the Tag .type.. The ownership of that dependency is represented in the «categorization type» element by the Tag .categorization.. The relationship of the «categorization» Dependency to the (supplier) Class that is the base concept is represented in the «categorization» element with the Tag .base concept.. J.3 Verb Concepts The SBVR term verb concept refers to a concept whose instances are states, activities or events. All of the verb concepts in this specification can be understood to represent states. A verb concept is said to have verb concept roles that characterize the participation of individual objects in those states, activities or events. States Verb concepts that involve only one or two participant objects can be represented in UML via using Attributes and binary Associations. In a binary Association, the multiplicity on an Association End represents the number of instances of the verb concept that each instance of the other role can participate in, i.e., the number of times an instance of that class can play that role. In theory, a state verb concept involving more than two participants roles can be represented in UML by an N-ary Association. The problem is that the meaning of the multiplicities in an n-ary Association cannot be easily related to states, and the number of instances of the verb conceptsuch states in which a given instance of a participating class participates in cannot be documented as a multiplicity. The multiplicity on an Association end is instead a function of n-1 arguments (the things playing all the other roles). A UML AssociationClass that is an Association with more than two AssociationEnds is an N-ary Association and has this same problem with multiplicities. For this reason, this specification represents a verb concept with 3 or more participating verb concept roles as a class with a «verb concept» stereotype, which is conceptually similar to the (now deprecated) UML Association Class. Two stereotypes are introduced to support this approach. J.3.1 Stereotype «verb concept» The stereotype «verb concept» characterizes a UML Class as an SBVR verb concept. In UML terms, it is a classifier whose instances are states. Each «verb concept» Class has one «verb concept role» Association for each verb concept role in the SBVR verb concept that it represents. The set of «verb concept role» Associations for the verb concept are represented in the «verb concept» element by the Tag .roles.. The number of verb concept roles for the verb concept is represented in the «verb concept» element by the Tag .arity.. J.3.2 Stereotype «verb concept role» The stereotype «verb concept role» characterizes a UML Association as representing one verb concept role in an SBVR verb concept that is represented by a «verb concept» Class. Each «verb concept role» Association represents exactly one verb concept role in exactly one SBVR verb concept. Each link that instantiates that Association can be read: In the state (object) X that is the instance of the verb concept Class, the role Y is played by Z, where Y is the association end name on the Association, and Z is the object in the range Class. One end of the «verb concept role» Association is the «verb concept» Class that represents the verb concept. The other end of the Association is the UML Class that represents the range of the verb concept role. The name of that association end is the placeholder for the verb concept role in the verb concept form. In a «verb concept role» Association only the association end that refers to the range of the role is navigable, and it always has multiplicity one, because each verb concept role is played exactly once in any one instance of the verb concept. The relationship of the «verb concept role» Association to the «verb concept» Class is represented in the «verb concept role» element by the Tag .verb concept.. Disposition: Resolved To: date-time-ftf@omg.org Subject: Re: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 X-KeepSent: 85ABA319:5F300CF0-85257A4E:0053EBB5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Thu, 2 Aug 2012 11:17:16 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 08/02/2012 11:17:18, Serialize complete at 08/02/2012 11:17:18 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12080215-7182-0000-0000-000002261802 This looks good to me. But do we want to add a stereotype for <>? -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: "date-time-ftf@omg.org" , Date: 07/31/2012 07:02 PM Subject: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 -------------------------------------------------------------------------------- I attach a new draft of the resolution to DTV Issue 17129, addressing all the points in the email discussion of last week (below). -Ed Ed Barkmeyer wrote: Mark H Linehan wrote: 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] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [attachment "DTV Issue 17129 - Define the UML Profile for SBVR-d2.docx" deleted by Mark H Linehan/Watson/IBM] Date: Thu, 2 Aug 2012 12:02:33 -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 Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q72G2dqw026715 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1344528163.30965@bEzogTSdIngw/bcm19p+pQ X-Spam-Status: No Mark H Linehan wrote: This looks good to me. But do we want to add a stereotype for <>? The origin of Mark's question is the current draft resolution of Issue 16951 - time point subdivision - which contains an intensional role. So, before we consider adding a stereotype, we need to consider two questions: (1) Do we like the draft resolution of 16951? Is the use of the 'intensional role' in 'finite time scale subdivides time point1 into number of time point2*' even the right idea? I'm happy to hold on 17129 until 16951 is resolved. (2) Do we want to use an 'intensional role' at all in DTV? An intensional role is a declaration that the range of the role is specializations of the nominal 'range' concept rather than instances of the range concept, and SBVR has no verb concept that supports that notion. The 'intensional role' concept is described only in the non-normative Annex C. So, using this thing in the DTV vocabulary puts us on shaky ground. Finally, we may not need a stereotype, because the UML concept "powertype" is the intended concept. That is, one could say that the range of the role 'time point2*' is an unnamed "powertype" of 'time point'. But, unlike categorization types, in this case the UML concept is what is meant, and SBVR does not have that concept, either. (I don't think 'time point' has any overlapping specializations, however.) -Ed -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: "date-time-ftf@omg.org" , Date: 07/31/2012 07:02 PM Subject: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 -------------------------------------------------------------------------------- I attach a new draft of the resolution to DTV Issue 17129, addressing all the points in the email discussion of last week (below). -Ed Ed Barkmeyer wrote: Mark H Linehan wrote: 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] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [attachment "DTV Issue 17129 - Define the UML Profile for SBVR-d2.docx" deleted by Mark H Linehan/Watson/IBM] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Mike Bennett To: "edbark@nist.gov" , Mark H Linehan CC: "date-time-ftf@omg.org" Subject: RE: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 Thread-Topic: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 Thread-Index: AQHNb3Bq/xeCANYz0Ui0zzYSmIHsppdHGkQAgAAMp4D//6BeQA== Date: Thu, 2 Aug 2012 17:21:29 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.136.152.24] If you do decide you need such a stereotype, you might need to check that the spelling is intensional and not intentional as this may cause confusion further down the line. (an easy typo to make, I realize, but I thought I should pick it out now in case it gets missed later) Mike -- Mike Bennett Head of Semantics and Standards EDM Council Tel: +44 20 7917 9522 Cell: +44 7721 420 730 www.edmcouncil.org Semantics Repository: www.hypercube.co.uk/edmcouncil From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Thursday, August 02, 2012 12:03 PM To: Mark H Linehan Cc: date-time-ftf@omg.org Subject: Re: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 Mark H Linehan wrote: This looks good to me. But do we want to add a stereotype for <>? The origin of Mark's question is the current draft resolution of Issue 16951 - time point subdivision - which contains an intensional role. So, before we consider adding a stereotype, we need to consider two questions: (1) Do we like the draft resolution of 16951? Is the use of the 'intensional role' in 'finite time scale subdivides time point1 into number of time point2*' even the right idea? I'm happy to hold on 17129 until 16951 is resolved. (2) Do we want to use an 'intensional role' at all in DTV? An intensional role is a declaration that the range of the role is specializations of the nominal 'range' concept rather than instances of the range concept, and SBVR has no verb concept that supports that notion. The 'intensional role' concept is described only in the non-normative Annex C. So, using this thing in the DTV vocabulary puts us on shaky ground. Finally, we may not need a stereotype, because the UML concept "powertype" is the intended concept. That is, one could say that the range of the role 'time point2*' is an unnamed "powertype" of 'time point'. But, unlike categorization types, in this case the UML concept is what is meant, and SBVR does not have that concept, either. (I don't think 'time point' has any overlapping specializations, however.) -Ed -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: "date-time-ftf@omg.org" , Date: 07/31/2012 07:02 PM Subject: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 -------------------------------------------------------------------------------- I attach a new draft of the resolution to DTV Issue 17129, addressing all the points in the email discussion of last week (below). -Ed Ed Barkmeyer wrote: Mark H Linehan wrote: 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] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [attachment "DTV Issue 17129 - Define the UML Profile for SBVR-d2.docx" deleted by Mark H Linehan/Watson/IBM] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Thu, 2 Aug 2012 13:46:15 -0400 From: Edward Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mike Bennett CC: Mark H Linehan , "date-time-ftf@omg.org" Subject: Re: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 Mike Bennett wrote: If you do decide you need such a stereotype, you might need to check that the spelling is intensional and not intentional as this may cause confusion further down the line. Indeed. The term in Annex C is 'intensional' with an S. It refers to the concepts, not the instances (the 'extension'). "Intentional", with a T is about purpose. -Ed (an easy typo to make, I realize, but I thought I should pick it out now in case it gets missed later) Mike -- Mike Bennett Head of Semantics and Standards EDM Council Tel: +44 20 7917 9522 Cell: +44 7721 420 730 www.edmcouncil.org Semantics Repository: www.hypercube.co.uk/edmcouncil *From:* Ed Barkmeyer [mailto:edbark@nist.gov] *Sent:* Thursday, August 02, 2012 12:03 PM *To:* Mark H Linehan *Cc:* date-time-ftf@omg.org *Subject:* Re: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 Mark H Linehan wrote: This looks good to me. But do we want to add a stereotype for <>? The origin of Mark's question is the current draft resolution of Issue 16951 - time point subdivision - which contains an intensional role. So, before we consider adding a stereotype, we need to consider two questions: (1) Do we like the draft resolution of 16951? Is the use of the 'intensional role' in 'finite time scale subdivides time point1 into number of time point2*' even the right idea? I'm happy to hold on 17129 until 16951 is resolved. (2) Do we want to use an 'intensional role' at all in DTV? An intensional role is a declaration that the range of the role is /specializations/ of the nominal 'range' concept rather than /instances/ of the range concept, and SBVR has no verb concept that supports that notion. The 'intensional role' concept is described only in the non-normative Annex C. So, using this thing in the DTV vocabulary puts us on shaky ground. Finally, we may not need a stereotype, because the UML concept "powertype" is the intended concept. That is, one could say that the range of the role 'time point2*' is an unnamed "powertype" of 'time point'. But, unlike categorization types, in this case the UML concept is what is meant, and SBVR does not have that concept, either. (I don't think 'time point' has any overlapping specializations, however.) -Ed -------------------------------- Mark H. Linehan STSM, IBM Research From: Ed Barkmeyer To: "date-time-ftf@omg.org" , Date: 07/31/2012 07:02 PM Subject: DTV Issue 17129 -- UML Profile for SBVR concepts -- resolution draft 2 ------------------------------------------------------------------------ I attach a new draft of the resolution to DTV Issue 17129, addressing all the points in the email discussion of last week (below). -Ed Ed Barkmeyer wrote: Mark H Linehan wrote: _ 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 role_s" 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] -- 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 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [attachment "DTV Issue 17129 - Define the UML Profile for SBVR-d2.docx" deleted by Mark H Linehan/Watson/IBM] -- 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 "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 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: date-time-ftf@omg.org Subject: Date-Time Issue 17129: need profile for UML stereotypes X-KeepSent: 26A1583F:D2858C59-85257A56:0079E6B9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Fri, 10 Aug 2012 18:13:24 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 08/10/2012 18:13:24, Serialize complete at 08/10/2012 18:13:24 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12081022-6078-0000-0000-00000E209BDE In reviewing the ballot 1 convenience document, I noticed various places in the Scope and other sections where these obsolete terms are used: "fact type", "fact type role", "fact symbol". I wonder if we should add to 17129 a global change of these terms to the equivalent new ones. -------------------------------- Mark H. Linehan STSM, IBM Research Date: Fri, 31 Aug 2012 18:28:42 -0400 From: Ed Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: OMG DateTimeVoc FTF Subject: DTV Issue 17129 UML Profile for SBVR revised X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q7VMSk87017160 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1347056928.7173@3ywfrMfP2QfrhGfJqImK+g X-Spam-Status: No All, In repairing a UML diagram for another issue, I realized that the <> stereotype is actually used in the DTV UML models. So I added it to the UML profile. I attach the corresponding revision of the resolution to Issue 17129, with changes highlighted. -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-d3.docx Disposition: Resolved OMG Issue No: 17129 Title: Need Profile for UML Stereotypes Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile. Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match. Resolution: The FTF agrees that there should be a formal UML profile for the stereotypes in the DTV specification. The FTF believes that it is in the best interest of SBVR users and developers that a UML Profile for SBVR be developed by the OMG as an extension to SBVR. In the interim, the FTF agrees to document the profile used in DTV in a DTV annex. Revised Text: 1. In clause 5.2, at the end of the 3rd paragraph (immediately before the bullet list), ADD a sentence: Some SBVR vocabulary items are modeled in the UML model using stereotypes. The stereotypes are formally specified in the UML Profile for SBVR in Annex J. 2. In clause 5.2, in the bullet list, REPLACE the bullet: . Each SBVR object type maps to a UML class. with three bullets: . Each SBVR general concept maps to a UML class. . Each SBVR concept type maps to a UML class with the stereotype «concept type». Where specific concepts that are instances of a concept type are also modeled, the fact that each such a concept is an instance of the concept type is modeled by a UML dependency with the stereotype «instance». . Each SBVR categorization type maps to a UML class with the stereotype «categorization type». The relationship between the categorization type and the general concept it categorizes is modeled by a UML dependency with the stereotype «categorization». 3. In clause 5.2, in the bullet list, in the bullet: . Each SBVR verb concept that uses the fact symbol has maps to a UML property. CHANGE .fact symbol. to .verb symbol.. 4. In clause 5.2, in the bullet list, in the bullet beginning: . Verb concepts with more than two roles map to UML classes stereotyped as <> CHANGE both occurrences of <> to «verb concept», and in the paragraph below the bullet, CHANGE all four occurrences of .fact type. to .verb concept.. 5. In clause 5.2, in the bullet list, in the bullet beginning: . SBVR roles map to UML property names , . REPLACE <> with «verb concept role». 6. In clause 5.2 DELETE Table 5.1 UML Stereotypes entirely, and DELETE the preceding sentence: Several stereotypes are employed to relate UML model elements to SBVR concepts: 7. CREATE a new Annex (tentatively designated Annex J) as follows: Annex J UML Profile for SBVR (normative) This annex specifies the stereotypes that are used to mark up UML model elements in the DTV specification. A general UML Profile for SBVR concepts has not been developed by the OMG. It is expected that such a profile will be developed in the future. At such time, this Annex and the corresponding UML stereotypes in the DTV UML model will be superseded. The UML stereotypes used in this specification are depicted in Figure J-1 and described in detail below. Figure J-1: UML Profile for SBVR The UML metaclass Class is depicted in the diagram because it plays roles in stereotyped relationships. The UML metaclasses Association and Dependency are not depicted. They serve only as the UML base elements for some of the defined stereotypes. J.1 Concept types The SBVR term concept type refers to a concept whose instances are concepts. Two stereotypes are introduced to support this notion. J.1.1 Stereotype «concept type» The stereotype «concept type» characterizes a UML Class as an SBVR concept type. In UML terms, it is a classifier whose instances are classes. J.1.2 Stereotype «instance» The stereotype «instance» characterizes a UML Dependency as representing the relationship between a UML Class (representing an SBVR concept) and a concept type that corresponds to it. That is, the Dependency can be read .Class X is an instance of concept type Y.. The relationship of the «instance» Dependency to the (client) Class that is the instance is represented in the «instance» element by the Tag .instance.. The relationship of the «instance» Dependency to the (supplier) Class that is the concept type is represented in the «instance» element with the Tag .type.. J.2 Categorization types The SBVR term categorization type refers to a concept type whose instances are mutually exclusive subtypes of a common base concept. Two stereotypes are introduced to support this notion. J.2.1 Stereotype «categorization type» The stereotype «categorization type» characterizes a UML Class as an SBVR categorization type. A categorization type is similar to a UML Powertype. The instances of a Powertype are all the subclasses of a given Class. By comparison, the extension of a categorization type is a particular set of subclasses of a given Class that are mutually exclusive. Only in some cases is the extension of a UML Powertype a set of subclasses that are mutually exclusive, partly because the Powertype necessarily includes all of the subclasses of the categorized Class. Each categorization type has a «categorization» Dependency on a 'base class' that is the "common base concept" of the instances. J.2.2 Stereotype «categorization» The stereotype «categorization» characterizes a UML Dependency as representing the relationship between a categorization type and the base concept that it categorizes. The base concept is represented by a UML Class (representing an SBVR concept). That is, the Dependency can be read .Categorization type X categorizes concept Y.. The relationship of the «categorization» Dependency to the (client) categorization type is represented in the «categorization» element by the Tag .type.. The ownership of that dependency is represented in the «categorization type» element by the Tag .categorization.. The relationship of the «categorization» Dependency to the (supplier) Class that is the base concept is represented in the «categorization» element with the Tag .base concept.. J.3 Verb Concepts The SBVR term verb concept refers to a concept whose instances are states, activities or events. A verb concept is said to have verb concept roles that characterize the participation of individual objects in those states, activities or events. Verb concepts that involve only one or two participant objects can be represented in UML using Attributes and binary Associations. In a binary Association, the multiplicity on an Association End represents the number of instances of the verb concept that each instance of the other role can participate in, i.e., the number of times an instance of that class can play that role. In theory, a verb concept involving more than two roles can be represented in UML by an N-ary Association. The problem is that the multiplicities in an n-ary Association cannot be easily related to the number of instances of the verb concept a given instance of a participating class participates in. The multiplicity on an Association end is instead a function of n-1 arguments (the things playing all the other roles). A UML AssociationClass that is an Association with more than two AssociationEnds is an N-ary Association and has this same problem with multiplicities. For this reason, this specification represents a verb concept with 3 or more participating verb concept roles as a class with a «verb concept» stereotype. Two stereotypes are introduced to support this approach. J.3.1 Stereotype «verb concept» The stereotype «verb concept» characterizes a UML Class as an SBVR verb concept. In UML terms, it is a classifier whose instances are states. Each «verb concept» Class has one «verb concept role» Association for each verb concept role in the SBVR verb concept that it represents. The set of «verb concept role» Associations for the verb concept are represented in the «verb concept» element by the Tag .roles.. The number of verb concept roles for the verb concept is represented in the «verb concept» element by the Tag .arity.. J.3.2 Stereotype «verb concept role» The stereotype «verb concept role» characterizes a UML Association as representing one verb concept role in an SBVR verb concept that is represented by a «verb concept» Class. Each «verb concept role» Association represents exactly one verb concept role in exactly one SBVR verb concept. Each link that instantiates that Association can be read: In the state (object) X that is the instance of the verb concept Class, the role Y is played by Z, where Y is the association end name on the Association, and Z is the object in the range Class. One end of the «verb concept role» Association is the «verb concept» Class that represents the verb concept. The other end of the Association is the UML Class that represents the range of the verb concept role. The name of that association end is the placeholder for the verb concept role in the verb concept form. In a «verb concept role» Association only the association end that refers to the range of the role is navigable, and it always has multiplicity one, because each verb concept role is played exactly once in any one instance of the verb concept. The relationship of the «verb concept role» Association to the «verb concept» Class is represented in the «verb concept role» element by the Tag .verb concept.. J.3.2 Stereotype «specializes» The stereotype «specializes» characterizes a UML Dependency as representing an instance of SBVR concept specializes concept, where the narrower concept is a binary verb concept that is represented by a UML Association, and the more general concept is a verb concept with more than two verb concept roles that is represented by a «verb concept» Class. That is, the Dependency can be read .binary verb concept X specializes verb concept Y.. The relationship of the «specializes» Dependency to the (client) binary verb concept is represented in the «specializes» element by the Tag .binary verb.. The relationship of the «specializes» Dependency to the (supplier) «verb concept» Class that is the more general verb concept is represented in the «specializes» element with the Tag .n-ary verb.. Note: A binary verb concept can specialize an n-ary verb concept by supplying in its definition a specific thing to play one of the verb concept roles in the n-ary verb concept. In practice, it also constrains the ranges of other verb concept roles in the n-ary verb concept. Disposition: Resolved Date: Fri, 5 Oct 2012 14:52:20 -0400 From: Edward Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Markus Schacher CC: "date-time-ftf@omg.org" Subject: Re: Issue 17129 (DTV Ballot 2 - Votes due Friday, October 5) Markus Schacher wrote: Ed, I would base a categorization on a UML GeneralizationSet as this is the extent representing the powertype of a You are probably right in basing a categorization on a class, but it must be a class that is related to a UML GeneralizationSet that is the extent represented by the powertype representing the categorization. With respect to n-ary associations: we use ternary associations in Artisan Studio as well as our SBVR profile on top of it for many years now. However, I.ve never tested the XMI produced from these models. Best regards, Markus Thanks. This is interesting. I like the idea that a categorization type is a GeneralizationSet. That is essentially what the SBVR UML diagrams are trying to convey. But that leads to the question: What is the diagrammatic representation of a GeneralizationSet and how can one name it? I can't even figure out how to get MagicDraw v17 to create one, although it insists on drawing the "rake" structure, even when it is not intended! Further, consider the model snippet in issue 17404. 'quantity kind' is a categorization type, but the specific GeneralizationSet is not documented. And in fact, the actual set will be defined by the chosen System of Quantities. I suspect that this may mean it is mischaracterized as a categorization type? And OBTW, a categorization is not a UML:powertype, that is, it is not defined to be all the subclasses of a given class. As you say, it is the set of subclasses in a particular GeneralizationSet. With respect to n-ary associations, upon reflection, I fully agree that the UML n-ary Association is what should be used. The remaining problem is to get consistent support across UML tools. I have not used the Artisan tool. I wish we had discussed this issue earlier... I think I should vote Yes on the Issue resolution and then move to "rescind" the adoption of this resolution on the next ballot. That will leave the issue unresolved, and permit an alternative resolution to be created. Do you want to do that? Alternatively, I can vote No and hope that it fails, but then someone who voted Yes would have to move to rescind the adoption if it passes. I would like you and Nicolas to take this over. -Ed From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Dienstag, 2. Oktober 2012 23:14 To: Markus Schacher Cc: date-time-ftf@omg.org Subject: Re: DTV Ballot 2 - Votes due Friday, October 5 Markus, you wrote: RESOLVED Issue 17129 - Need Profile for UML Stereotypes ____ Yes _X_ No ____ Abstain I think to base .verb concepts. and probably .categorization types. on the metaclass .Class. doesn.t work. Particularly binary and higher verb concepts should be based on associations. Even if a class would be used as a base for a verb concept, it should be an association class as between the same two concept types the same verb concept may not be defined more than once. Verb concept roles could be stereotyped UML roles/properties/association ends. The stereotype could probably be used to represent objectified verb concepts. Unary verb concepts are more problematic in UML. Finally, the diagram should show all .Extensions. associations of the stereotypes introduced here. A categorization type is a concept whose instances are concepts If not UML Class, then what else would you base it on? Binary verb concepts ARE represented by UML associations in the UML model. The problem is N-ary verb concepts where N>2, as the proposed text says. I would have preferred to use ternary associations for ternary verb concepts, but at this moment, I still don't know whether any UML tool supports them properly. If you can identify one that does, and gets the XMI right, then we should change the UML model. But the last time I experimented with a ternary relation, MagicDraw exported a uml:Class in the XMI, so the stereotype seemed to be an improvement. And AssociationClasses seem to be necessarily binary associations in the two UML tools I have. I'm not sure whether the Model Interchange WG has a test for whatever conformance to UML N-ary associations may require. I put those stereotypes into the submission diagrams in July 2011, and I asked what the team wanted to do about that. We had an FTF issue saying they should be documented, and I asked again in June 2012 whether we wanted to change them. According to my notes, the first draft of this resolution was sent out at the end of July. The second draft was sent out at the end of August. It is now October, and it would greatly have helped if we could have discussed this anytime in the last 3 months. So, when you write up a viable alternative, I will be happy to throw this Profile away. We obviously should have assigned Issue 17129 to you. If you don't have time between now and 12 November, you can write up a new Issue on this for the RTF, and it will be assigned to you, I guarantee. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "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 Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 05 Oct 2012 11:58:42 -0700 From: Elisa Kendall Organization: Thematix Partners LLC User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 To: "date-time-ftf@omg.org" Subject: Re: Issue 17129 (DTV Ballot 2 - Votes due Friday, October 5) Ed, I can help you create/name it in MagicDraw, perhaps via webex at some point next week, but there are gremlins under the covers if one wants to access the model programmatically. I can also chime in on best practices in modeling some of this from an ontological perspective if that would be helpful. Let me know, and have a nice weekend, Elisa On 10/5/2012 11:52 AM, Edward Barkmeyer wrote: Markus Schacher wrote: Ed, I would base a categorization on a UML GeneralizationSet as this is the extent representing the powertype of a You are probably right in basing a categorization on a class, but it must be a class that is related to a UML GeneralizationSet that is the extent represented by the powertype representing the categorization. With respect to n-ary associations: we use ternary associations in Artisan Studio as well as our SBVR profile on top of it for many years now. However, I.ve never tested the XMI produced from these models. Best regards, Markus Thanks. This is interesting. I like the idea that a categorization type is a GeneralizationSet. That is essentially what the SBVR UML diagrams are trying to convey. But that leads to the question: What is the diagrammatic representation of a GeneralizationSet and how can one name it? I can't even figure out how to get MagicDraw v17 to create one, although it insists on drawing the "rake" structure, even when it is not intended! Further, consider the model snippet in issue 17404. 'quantity kind' is a categorization type, but the specific GeneralizationSet is not documented. And in fact, the actual set will be defined by the chosen System of Quantities. I suspect that this may mean it is mischaracterized as a categorization type? And OBTW, a categorization is not a UML:powertype, that is, it is not defined to be all the subclasses of a given class. As you say, it is the set of subclasses in a particular GeneralizationSet. With respect to n-ary associations, upon reflection, I fully agree that the UML n-ary Association is what should be used. The remaining problem is to get consistent support across UML tools. I have not used the Artisan tool. I wish we had discussed this issue earlier... I think I should vote Yes on the Issue resolution and then move to "rescind" the adoption of this resolution on the next ballot. That will leave the issue unresolved, and permit an alternative resolution to be created. Do you want to do that? Alternatively, I can vote No and hope that it fails, but then someone who voted Yes would have to move to rescind the adoption if it passes. I would like you and Nicolas to take this over. -Ed From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Dienstag, 2. Oktober 2012 23:14 To: Markus Schacher Cc: date-time-ftf@omg.org Subject: Re: DTV Ballot 2 - Votes due Friday, October 5 Markus, you wrote: RESOLVED Issue 17129 - Need Profile for UML Stereotypes ____ Yes _X_ No ____ Abstain I think to base .verb concepts. and probably .categorization types. on the metaclass .Class. doesn.t work. Particularly binary and higher verb concepts should be based on associations. Even if a class would be used as a base for a verb concept, it should be an association class as between the same two concept types the same verb concept may not be defined more than once. Verb concept roles could be stereotyped UML roles/properties/association ends. The stereotype could probably be used to represent objectified verb concepts. Unary verb concepts are more problematic in UML. Finally, the diagram should show all .Extensions. associations of the stereotypes introduced here. A categorization type is a concept whose instances are concepts If not UML Class, then what else would you base it on? Binary verb concepts ARE represented by UML associations in the UML model. The problem is N-ary verb concepts where N>2, as the proposed text says. I would have preferred to use ternary associations for ternary verb concepts, but at this moment, I still don't know whether any UML tool supports them properly. If you can identify one that does, and gets the XMI right, then we should change the UML model. But the last time I experimented with a ternary relation, MagicDraw exported a uml:Class in the XMI, so the stereotype seemed to be an improvement. And AssociationClasses seem to be necessarily binary associations in the two UML tools I have. I'm not sure whether the Model Interchange WG has a test for whatever conformance to UML N-ary associations may require. I put those stereotypes into the submission diagrams in July 2011, and I asked what the team wanted to do about that. We had an FTF issue saying they should be documented, and I asked again in June 2012 whether we wanted to change them. According to my notes, the first draft of this resolution was sent out at the end of July. The second draft was sent out at the end of August. It is now October, and it would greatly have helped if we could have discussed this anytime in the last 3 months. So, when you write up a viable alternative, I will be happy to throw this Profile away. We obviously should have assigned Issue 17129 to you. If you don't have time between now and 12 November, you can write up a new Issue on this for the RTF, and it will be assigned to you, I guarantee. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "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 Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Markus Schacher To: "edbark@nist.gov" CC: "date-time-ftf@omg.org" , "Artisan Support (artisan-support@atego.com)" , Andreas Korff Subject: RE: Issue 17129 (DTV Ballot 2 - Votes due Friday, October 5) Thread-Topic: Issue 17129 (DTV Ballot 2 - Votes due Friday, October 5) Thread-Index: AQHNoyqRCA5l5ZfKdEWcnk81UNkF85etSyIw Date: Sun, 7 Oct 2012 05:23:21 +0000 Accept-Language: de-CH, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.60.249.28] Ed, My experience is that in UML GeneralizatioSets must be visible at least by their name on all Generalizations that belong to the same GeneralizationSet (see e.g. figure 7.42 in UML 2.4.1 Superstructure). However, some tools (such as Artisan Studio) have difficulties to properly relate a GeneralizationSet to the Class(ifier) that represents the actual powertype. I.m also not sure whether UML (2.4.1) is clean here as I do not understand the 0..1 to * association between Classifier and GeneralizationSet (reuse of Classifiers across multiple GeneralizationSets?). Best regards, Markus From: Edward Barkmeyer [mailto:edward.barkmeyer@nist.gov] Sent: Freitag, 5. Oktober 2012 20:52 To: Markus Schacher Cc: date-time-ftf@omg.org Subject: Re: Issue 17129 (DTV Ballot 2 - Votes due Friday, October 5) Markus Schacher wrote: Ed, I would base a categorization on a UML GeneralizationSet as this is the extent representing the powertype of a You are probably right in basing a categorization on a class, but it must be a class that is related to a UML GeneralizationSet that is the extent represented by the powertype representing the categorization. With respect to n-ary associations: we use ternary associations in Artisan Studio as well as our SBVR profile on top of it for many years now. However, I.ve never tested the XMI produced from these models. Best regards, Markus Thanks. This is interesting. I like the idea that a categorization type is a GeneralizationSet. That is essentially what the SBVR UML diagrams are trying to convey. But that leads to the question: What is the diagrammatic representation of a GeneralizationSet and how can one name it? I can't even figure out how to get MagicDraw v17 to create one, although it insists on drawing the "rake" structure, even when it is not intended! Further, consider the model snippet in issue 17404. 'quantity kind' is a categorization type, but the specific GeneralizationSet is not documented. And in fact, the actual set will be defined by the chosen System of Quantities. I suspect that this may mean it is mischaracterized as a categorization type? And OBTW, a categorization is not a UML:powertype, that is, it is not defined to be all the subclasses of a given class. As you say, it is the set of subclasses in a particular GeneralizationSet. With respect to n-ary associations, upon reflection, I fully agree that the UML n-ary Association is what should be used. The remaining problem is to get consistent support across UML tools. I have not used the Artisan tool. I wish we had discussed this issue earlier... I think I should vote Yes on the Issue resolution and then move to "rescind" the adoption of this resolution on the next ballot. That will leave the issue unresolved, and permit an alternative resolution to be created. Do you want to do that? Alternatively, I can vote No and hope that it fails, but then someone who voted Yes would have to move to rescind the adoption if it passes. I would like you and Nicolas to take this over. -Ed From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Dienstag, 2. Oktober 2012 23:14 To: Markus Schacher Cc: date-time-ftf@omg.org Subject: Re: DTV Ballot 2 - Votes due Friday, October 5 Markus, you wrote: RESOLVED Issue 17129 - Need Profile for UML Stereotypes ____ Yes _X_ No ____ Abstain I think to base .verb concepts. and probably .categorization types. on the metaclass .Class. doesn.t work. Particularly binary and higher verb concepts should be based on associations. Even if a class would be used as a base for a verb concept, it should be an association class as between the same two concept types the same verb concept may not be defined more than once. Verb concept roles could be stereotyped UML roles/properties/association ends. The stereotype could probably be used to represent objectified verb concepts. Unary verb concepts are more problematic in UML. Finally, the diagram should show all .Extensions. associations of the stereotypes introduced here. A categorization type is a concept whose instances are concepts If not UML Class, then what else would you base it on? Binary verb concepts ARE represented by UML associations in the UML model. The problem is N-ary verb concepts where N>2, as the proposed text says. I would have preferred to use ternary associations for ternary verb concepts, but at this moment, I still don't know whether any UML tool supports them properly. If you can identify one that does, and gets the XMI right, then we should change the UML model. But the last time I experimented with a ternary relation, MagicDraw exported a uml:Class in the XMI, so the stereotype seemed to be an improvement. And AssociationClasses seem to be necessarily binary associations in the two UML tools I have. I'm not sure whether the Model Interchange WG has a test for whatever conformance to UML N-ary associations may require. I put those stereotypes into the submission diagrams in July 2011, and I asked what the team wanted to do about that. We had an FTF issue saying they should be documented, and I asked again in June 2012 whether we wanted to change them. According to my notes, the first draft of this resolution was sent out at the end of July. The second draft was sent out at the end of August. It is now October, and it would greatly have helped if we could have discussed this anytime in the last 3 months. So, when you write up a viable alternative, I will be happy to throw this Profile away. We obviously should have assigned Issue 17129 to you. If you don't have time between now and 12 November, you can write up a new Issue on this for the RTF, and it will be assigned to you, I guarantee. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "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 Systems Integration Division, Engineering Laboratory 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority."