Issue 16233: SMOF does not implement dynamic classification of associations (smof-ftf) Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com) Nature: Uncategorized Issue Severity: Summary: SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 – and A by B. But SMOF doesn’t allow the “A by B” part. Resolution: Revised Text: Actions taken: May 12, 2011: received issue Discussion: Discussion: Implementing dynamic classification of associations in SMOF would be a large piece of work; particularly it requires major upheaval in the Semantics section. Every link would need to have multiple slots at either end, and a load of constraints to ensure that all of the slots at each end have the same value. The notion of “opposite” slot would need to be substantially modified. Several questions remain unanswered in my mind. Is it possible to multiply classify a composition with a non-composition? Is it possible to multiply classify a composition with a composition in the other direction? If one or more of the classifying associations has properties which are derived and/or navigable and/or class-owned, what are the restrictions on multiple classification? What about association end subsetting and redefinition? Can the notions of compatibility or incompatibility be wholly or partially derived? What is the impact on XMI serialization? Given the problems we had coming up with a satisfactory interpretation of MOF semantics to resolve the recent urgent issue on how to serialize StructuredActivityNode, I am very nervous about being able to answer these questions in a satisfactory way. This is technically very tricky and I feel that a correct solution is out of my reach without investing a disproportionate amount of time and energy: I would have to build a working prototype, and I don’t have time or resources to do that. My inclination, therefore, is to defer this issue. If at some future date this turns out to be a real practical requirement, I would suggest it is resolved in an SMOF 2.0 which might by that stage be able to build on more clearly formulated MOF semantics. Resolution: As already stated by the issue provider, multiple and/or dynamic classification and reclassification of associations is not trivial. The FTF membership agreed that the work required to address this issue would exceed the time limit of this FTF and shall be picked-up by a future group or submission. Revised Text: None. Disposition: Deferred End of Annotations:===== m: Steve Cook To: "issues@omg.org" CC: "smof-ftf@omg.org" Subject: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6w== Date: Thu, 12 May 2011 15:37:53 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: RE: SMOF does not implement dynamic classification of associations Date: Thu, 12 May 2011 14:16:24 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6wALnK+A From: "Pete Rivett" To: "Steve Cook" Cc: I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve From: Steve Cook To: Pete Rivett CC: "smof-ftf@omg.org" Subject: RE: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6wALnK+AABhatBA= Date: Fri, 13 May 2011 08:57:35 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: RE: SMOF does not implement dynamic classification of associations To: "Cory Casanave" Cc: "Pete Rivett - Adaptive" , smof-ftf@omg.org, "Steve Cook" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 May 2011 19:21:34 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 05/19/2011 19:21:36 Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve pic28432.gif From: Steve Cook To: Maged Elaasar , Cory Casanave CC: Pete Rivett - Adaptive , "smof-ftf@omg.org" , "Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov)" , "Ed Seidewitz (ed-s@modeldriven.com)" Subject: RE: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6wALnK+AABhatBAADcohsAE8eugAALYnkuA= Date: Mon, 23 May 2011 14:48:08 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve From: "Rouquette, Nicolas F (313K)" To: Steve Cook , Maged Elaasar CC: Cory Casanave , Pete Adaptive , "smof-ftf@omg.org" , "Ed Seidewitz (ed-s@modeldriven.com)" Date: Mon, 23 May 2011 16:11:39 -0700 Subject: Re: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwZnsY67e93KzTEQY+tm7EdzDsggA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: RE: SMOF does not implement dynamic classification of associations Date: Mon, 23 May 2011 19:15:08 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations thread-index: AcwZnsY67e93KzTEQY+tm7EdzDsggAAACFBQ From: "Cory Casanave" To: "Rouquette, Nicolas F (313K)" , "Steve Cook" , "Maged Elaasar" Cc: "Pete Rivett - Adaptive" , , "Ed Seidewitz" I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: RE: SMOF does not implement dynamic classification of associations Date: Mon, 23 May 2011 19:17:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations thread-index: AcwZnsY67e93KzTEQY+tm7EdzDsggAAACFBQAAArPnA= From: "Cory Casanave" To: "Cory Casanave" , "Rouquette, Nicolas F (313K)" , "Steve Cook" , "Maged Elaasar" Cc: "Pete Rivett - Adaptive" , , "Ed Seidewitz" Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve X-Yahoo-Newman-Id: 365692.27363.bm@omp1012.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306200439; bh=vU731TTJsuReS5wMxGZAT2PNtU6BlsyalnU4DHaaWi0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=zsXSdY9ikhCCq+pbkCF3OjNceSPz1yI2y7hYWjz6GMK/bbCnI7BWdg3fVU9dCVqnxaZ0EzSqshhji7fYgoNSXu6lD2j9RQ1mROsb7V44GmJKJuPpX1Jug6eDNX4ugBxJj0mGbURNy4z4GTbPFAZxz593DchICv7CTSoYI0CGCZM= X-Yahoo-SMTP: hkiTVgSswBAc0l9gNL6Ip56w3nyVirLXCuwIL9NuAk6t6z9e X-YMail-OSG: bln4P8IVM1m_JFsbWhNk4gCxeRjmCeFoKvu4KMVFV80sarI x9y.C.plcXP1nWmic7E.naVuxPwbfoCpVR_.Phw6YKWNhylUBXuqJY4QAQmd 4f4zUwuaf6KdXHQxxGitdRn4cUIEgK8iIe78lTMOpAa3poPXwYgkou.ROWeb TfPN3UMizTrlF4TTkBhr905nJZSpxbi42fvpuU.Bar0vKU4ffbRlnOm1iDUp dP7vfdPdFIBR_97ATPxoVzXSdakB7wG0taXefLkZaCLW6GM3zgQMaDuM46w_ 1viC5TMTZWlJFe_HacWDUBwA7mi0iL52oOHVJNWabegzHow8v5tZO9XrW9ji gyC2ByOdBy_hjn8QZelcwEgm9nsNYgJwmm8gPaNRO.aqhHEuqVQLH3tS3CQm EHlUP7cROF.yPOXDEzL7Vl7slOzJpRLIBIjX8 X-Yahoo-Newman-Property: ymail-3 Date: Mon, 23 May 2011 18:27:10 -0700 From: Elisa Kendall Organization: Sandpiper Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 To: Cory Casanave CC: "Rouquette, Nicolas F \(313K\)" , Steve Cook , Maged Elaasar , Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: RE: SMOF does not implement dynamic classification of associations Date: Mon, 23 May 2011 21:37:39 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations thread-index: AcwZsbv/XMsmLb7JSUqHguCkknfn9QAAGKQg From: "Cory Casanave" To: "Elisa Kendall" Cc: "Rouquette, Nicolas F (313K)" , "Steve Cook" , "Maged Elaasar" , "Pete Rivett - Adaptive" , , "Ed Seidewitz" Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Date: Mon, 23 May 2011 19:50:54 -0700 From: Elisa Kendall Organization: Sandpiper Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 To: Cory Casanave CC: "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar , Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 23 May 2011 23:10:52 -0400 Subject: Re: SMOF does not implement dynamic classification of associations From: James Odell To: Cory Casanave CC: "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar , Pete Rivett , , Ed Seidewitz , Elisa Kendall Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwZsbv/XMsmLb7JSUqHguCkknfn9QAAGKQgAAOEaWg= Cory, It sounds like you.re talking about multiple classification, not multiple inheritance. Multiple classification has to do with an object that is an instance of multiple classes. In contrast, multiple classification is a relationship solely between classes, where a class. .inherits. the the features of its superclasses. The may look similar, but at best they.re cousins. -Jim On 5/23/11 9:37 PM, "Cory Casanave" indited: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 23 May 2011 23:13:17 -0400 Subject: Re: SMOF does not implement dynamic classification of associations From: James Odell To: Elisa Kendall , Cory Casanave CC: "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar , Pete Rivett , , Ed Seidewitz Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwZwIagKSjC9eqWhkepmMriEaxquw== Ooops. I just read Elisa.s email, and it looks like she already said it. (That.s what I get for reading my email FIFO.) -Jim On 5/23/11 10:50 PM, "Elisa Kendall" indited: Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve Subject: Re: SMOF does not implement dynamic classification of associations To: Elisa Kendall Cc: Cory Casanave , Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Pete Rivett - Adaptive , smof-ftf@omg.org, Steve Cook X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 24 May 2011 09:45:59 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 05/24/2011 09:46:00 As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve pic04194.gif From: "Rouquette, Nicolas F (313K)" To: Maged Elaasar CC: Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Date: Tue, 24 May 2011 07:37:37 -0700 Subject: Re: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwaICEM/uNE3kJYS3OlwlJKH66LQw== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve pic041941.gif Subject: Re: SMOF does not implement dynamic classification of associations To: "Rouquette, Nicolas F (313K)" Cc: Cory Casanave , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 24 May 2011 10:49:49 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 05/24/2011 10:49:50 Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve pic29158.gif Subject: RE: SMOF does not implement dynamic classification of associations To: Steve Cook Cc: Cory Casanave , "Ed Seidewitz (ed-s@modeldriven.com)" , "Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov)" , Pete Rivett - Adaptive , "smof-ftf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 24 May 2011 10:55:24 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 05/24/2011 10:55:24 Steve, you say >> I want MyDog to appear in the nestedClassifier property for MyCat. yet you also say >> I want my Animals metamodel to be independent of UML. Isn't this somehow contradictory? If you want the dog to appear in both eatenDog and nestedClassifier properties, you can eithe relate eatenDog to nestedClasifier (like with a subset or redefinition) or if they are not related, you would put them in two unrelated collections. is a sinlgle collection, classified by two unrelated associations really necessary? Steve Cook Steve Cook 05/23/2011 10:48 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Cory Casanave cc Pete Rivett - Adaptive , "smof-ftf@omg.org" , "Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov)" , "Ed Seidewitz (ed-s@modeldriven.com)" Subject RE: SMOF does not implement dynamic classification of associations Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve pic09301.gif From: Steve Cook To: Maged Elaasar CC: Cory Casanave , "Ed Seidewitz (ed-s@modeldriven.com)" , "Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov)" , "Pete Rivett - Adaptive" , "smof-ftf@omg.org" Subject: RE: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6wALnK+AABhatBAADcohsAE8eugAALYnkuAAM5/3AAACJP0g Date: Tue, 24 May 2011 15:07:17 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] Maged, inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 24 May 2011 15:55 To: Steve Cook Cc: Cory Casanave; Ed Seidewitz (ed-s@modeldriven.com); Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov); Pete Rivett - Adaptive; smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Steve, you say >> I want MyDog to appear in the nestedClassifier property for MyCat. yet you also say >> I want my Animals metamodel to be independent of UML. Isn't this somehow contradictory? Not at all. It is an explicit decision that I want to make in the unification of these two metamodels, which is one of the things that SMOF sets out to enable. It is exactly the same kind of decision as unifying Cat with Class. If you want the dog to appear in both eatenDog and nestedClassifier properties, you can eithe relate eatenDog to nestedClasifier (like with a subset or redefinition) or if they are not related, you would put them in two unrelated collections. If I want to relate them just using MOF, then yes I can use subsetting, and make Cat a subclass. But if I wanted to relate them using MOF and association specialization, then MOF has a bug because it does not correctly support the semantics of association specialization, and that is evidenced in the definition of part of the reflective CMOF API that concerns links. is a sinlgle collection, classified by two unrelated associations really necessary? If I want to keep the metamodels separate, for SMOF scenarios, then yes. If I am in a profile scenario and I am happy to make the profile metamodel dependent on UML, then I could use subsetting for this particular example, assuming that profiles were fixed so that subsetting actually worked. Steve Cook Steve Cook 05/23/2011 10:48 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Cory Casanave cc Pete Rivett - Adaptive , "smof-ftf@omg.org" , "Rouquette, Nicolas F (316A) (nicolas.f.rouquette@jpl.nasa.gov)" , "Ed Seidewitz (ed-s@modeldriven.com)" Subject RE: SMOF does not implement dynamic classification of associations Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve From: "Rouquette, Nicolas F (313K)" To: Maged Elaasar CC: Cory Casanave , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Date: Tue, 24 May 2011 09:18:26 -0700 Subject: Re: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwaLjZScUx/y3gWS7+Bi0BlNPqrxA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> pic291581.gif Subject: Re: SMOF does not implement dynamic classification of associations To: "Rouquette, Nicolas F (313K)" Cc: Cory Casanave , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 24 May 2011 12:21:03 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 05/24/2011 12:21:04 How do you know, if OWL does not talk about links, that this maps to 1 link with two associatgions vs. 2 links with one association each? "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 12:18 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Cory Casanave , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> pic04267.gif Subject: RE: SMOF does not implement dynamic classification of associations Date: Tue, 24 May 2011 12:28:28 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations thread-index: AcwaLjZScUx/y3gWS7+Bi0BlNPqrxAAAC82g From: "Cory Casanave" To: "Rouquette, Nicolas F (313K)" , "Maged Elaasar" Cc: "Ed Seidewitz" , "Elisa Kendall" , "Pete Rivett - Adaptive" , , "Steve Cook" Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> Subject: RE: SMOF does not implement dynamic classification of associations Date: Tue, 24 May 2011 09:48:58 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwaLjZScUx/y3gWS7+Bi0BlNPqrxAAAC82gAADyfDA= From: "Pete Rivett" To: "Cory Casanave" , "Rouquette, Nicolas F (313K)" , "Maged Elaasar" Cc: "Ed Seidewitz" , "Elisa Kendall" , , "Steve Cook" Ø By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Note that you can have 2 independent links with the same association type . if the association is defined as nonunique in the (meta)model Pete From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Tuesday, May 24, 2011 9:28 AM To: Rouquette, Nicolas F (313K); Maged Elaasar Cc: Ed Seidewitz; Elisa Kendall; Pete Rivett; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies to A_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> From: "Rouquette, Nicolas F (313K)" To: Cory Casanave CC: Maged Elaasar , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Date: Tue, 24 May 2011 10:01:24 -0700 Subject: Re: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwaNDeW5Bm0PBq/RoyzSDh94ccUWA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized On May 24, 2011, at 9:28 AM, Cory Casanave wrote: Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. SPARQL allows us to make distinctions on the basis of structural equivalence. That is, the following are structurally different: case1: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) vs. case2: ObjectPropertyAssertion(Subject1, predicate1, Object1) vs. case3: ObjectPropertyAssertion(Subject1, predicate2, Object1) Structurally, we can also use SPARQL to find out whether there is a direct or indirect generalization relationship between predicate1 and predicate2. Of course, if we turn on OWL2 DL semantics and if the ontology is consistent, then we can use a reasoner to answer questions about which link(s) are consistent; somewhat independently of whether the links have been asserted explicitly (e.g. case1) or not (e.g., case2 and 3) according to the generalization relationships that can be inferred or have been explicitly asserted between predicate1 and predicate2. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. Yes, yes, yes!!! My point is that we have *no* identity at all for links that are classified by associations in any CMOF metamodel because the MOF2/XMI mapping specification does not represent instances of such associations in a form that has a an XMI identity we could refer to. In Steve's example, any link that is classified by the meta-association UML::A_nestedClassifier_class has no XMI identity at all. Therefore, it is impossible to conceive of having a link that would be classified by an association defined in a profile where that association would be a specialization of UML::A_nestedClassifier_class. This is the fundamental limitation we have that makes meta-associations second-class citizens in our current metamodeling architecture. The explanation is simple: UML is a CMOF metamodel but all of the serializations of *instances* of a UML model are subject to the EMOF limitations of the MOF2/XMI mapping. There are ways to fix this problem: a) change all associations in UML to have all of the ends owned by the association itself. This means that the CMOF UML metamodel would map into XML schemas and XML documents where instances of meta-associations would have XMI identity (see clause 6.5.3 in XMI2.1/2.1.1 and 6.4.3 in XMI2.4) b) make all associations in UML AssociationClasses instead of Association + fix the CMOF mapping rules to ensure that instances of AssociationClass in a CMOF metamodel map according to the rules for Class. That is, fix the *intent* in XMI2.4 where *all* associations, regardless of association end ownership, map to elements that have XMI identity. We still have to fix the CMOF mapping rules to make sure that an AssociationClass is mapped according to the EMOF rules for Classes. We still have to verify that the class-owned association ends are mapped in a sensible way. There may be other options. Regardless of which option is used, it's clear that there would be a difference in using EMOF-based XMI serialization vs. true CMOF-based XMI serialization. In the former, instances of meta-associations have no XMI identity at all; in the latter, they do and therefore become first-class entities we could further specialize. Independently of this, we would have to fix some OCL minutiae w.r.t. the definition of conformsTo() so that we could do subsets, redefinitions and generalizations across an extension boundary; something that we can't do currently. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. I don't understand what this means. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. Can't answer this because I don't understand what you are saying. - Nicolas. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies toA_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> Subject: RE: SMOF does not implement dynamic classification of associations Date: Tue, 24 May 2011 13:47:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMOF does not implement dynamic classification of associations thread-index: AcwaNDeW5Bm0PBq/RoyzSDh94ccUWAABFBlw From: "Cory Casanave" To: "Rouquette, Nicolas F (313K)" Cc: "Maged Elaasar" , "Ed Seidewitz" , "Elisa Kendall" , "Pete Rivett - Adaptive" , , "Steve Cook" Nicolas, I think we are getting down to the real need . that we want to have associations as .first class. and be able to use these associations as arguments in other associations. This is essential to supporting a .fact based. approach, such as what they do in the IDEAS framework. Once you do this then associations are .instances. and you want those instances to be able to have multiple types for the same reason as all the other SMOF multiple classifications. The UML lens on this would be as you say . that association classes are the representation of these .facts.. This end ownership thing is and, in my opinion, always has been baloney. The .ends. are part of the .semantic cluster. that is the association (each end and sometimes other links are derivatives of the fundamental fact being asserted). .End ownership. is an implementation concern, not an architectural one. Now, I have questions as to the wisdom of pushing MOF this far in places where other things already stand . but if you want MOF to compete in the world of semantic description, this is part of what is needed. [CBC]As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. [NR] I don't understand what this means. You can say f(a,c,b) and q(a,b,c) in FOL. You can.t say f:q(a,b,c) where f:q is a tuple with the type f and the type q that would be equivalent to (f(a,c,b) and q(a,b,c)). The reason that you may want such a thing is to you could say z(k,f:q(a,b,c)). Note that I am making up a logic here while making up a way to express it, the point being . you can.t do it in FOL (as far as I know). -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 1:01 PM To: Cory Casanave Cc: Maged Elaasar; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations On May 24, 2011, at 9:28 AM, Cory Casanave wrote: Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. SPARQL allows us to make distinctions on the basis of structural equivalence. That is, the following are structurally different: case1: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) vs. case2: ObjectPropertyAssertion(Subject1, predicate1, Object1) vs. case3: ObjectPropertyAssertion(Subject1, predicate2, Object1) Structurally, we can also use SPARQL to find out whether there is a direct or indirect generalization relationship between predicate1 and predicate2. Of course, if we turn on OWL2 DL semantics and if the ontology is consistent, then we can use a reasoner to answer questions about which link(s) are consistent; somewhat independently of whether the links have been asserted explicitly (e.g. case1) or not (e.g., case2 and 3) according to the generalization relationships that can be inferred or have been explicitly asserted between predicate1 and predicate2. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. Yes, yes, yes!!! My point is that we have *no* identity at all for links that are classified by associations in any CMOF metamodel because the MOF2/XMI mapping specification does not represent instances of such associations in a form that has a an XMI identity we could refer to. In Steve's example, any link that is classified by the meta-association UML::A_nestedClassifier_class has no XMI identity at all. Therefore, it is impossible to conceive of having a link that would be classified by an association defined in a profile where that association would be a specialization of UML::A_nestedClassifier_class. This is the fundamental limitation we have that makes meta-associations second-class citizens in our current metamodeling architecture. The explanation is simple: UML is a CMOF metamodel but all of the serializations of *instances* of a UML model are subject to the EMOF limitations of the MOF2/XMI mapping. There are ways to fix this problem: a) change all associations in UML to have all of the ends owned by the association itself. This means that the CMOF UML metamodel would map into XML schemas and XML documents where instances of meta-associations would have XMI identity (see clause 6.5.3 in XMI2.1/2.1.1 and 6.4.3 in XMI2.4) b) make all associations in UML AssociationClasses instead of Association + fix the CMOF mapping rules to ensure that instances of AssociationClass in a CMOF metamodel map according to the rules for Class. That is, fix the *intent* in XMI2.4 where *all* associations, regardless of association end ownership, map to elements that have XMI identity. We still have to fix the CMOF mapping rules to make sure that an AssociationClass is mapped according to the EMOF rules for Classes. We still have to verify that the class-owned association ends are mapped in a sensible way. There may be other options. Regardless of which option is used, it's clear that there would be a difference in using EMOF-based XMI serialization vs. true CMOF-based XMI serialization. In the former, instances of meta-associations have no XMI identity at all; in the latter, they do and therefore become first-class entities we could further specialize. Independently of this, we would have to fix some OCL minutiae w.r.t. the definition of conformsTo() so that we could do subsets, redefinitions and generalizations across an extension boundary; something that we can't do currently. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. I don't understand what this means. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. Can't answer this because I don't understand what you are saying. - Nicolas. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies toA_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> From: "Rouquette, Nicolas F (313K)" To: Cory Casanave CC: Maged Elaasar , Ed Seidewitz , Elisa Kendall , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Date: Tue, 24 May 2011 11:17:05 -0700 Subject: Re: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwaPsnt016eBOtkQemLLOYrJVnY+w== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Cory, The conversion from Association to AssociationClass is trivial to do in QVTO. The tricky part is the MOF/XMI mapping. In effect, this is the kind of issue where the only way to get confidence that the fix will work is to prototype it. Pete had asked me whether I could help developing a QVTO prototype of the mapping rules. Until recently, there hasn't been a significant business case for it but this issue may change that because at JPL, it would be very useful for us to have a true CMOF UML2.4 metamodel where we can do true semantic specialization of the UML metamodel in domain-specific profiles. I would like to know if vendors would be interested in exploring this further and perhaps supporting this effort. - Nicolas. On May 24, 2011, at 10:47 AM, Cory Casanave wrote: Nicolas, I think we are getting down to the real need . that we want to have associations as .first class. and be able to use these associations as arguments in other associations. This is essential to supporting a .fact based. approach, such as what they do in the IDEAS framework. Once you do this then associations are .instances. and you want those instances to be able to have multiple types for the same reason as all the other SMOF multiple classifications. The UML lens on this would be as you say . that association classes are the representation of these .facts.. This end ownership thing is and, in my opinion, always has been baloney. The .ends. are part of the .semantic cluster. that is the association (each end and sometimes other links are derivatives of the fundamental fact being asserted). .End ownership. is an implementation concern, not an architectural one. Now, I have questions as to the wisdom of pushing MOF this far in places where other things already stand . but if you want MOF to compete in the world of semantic description, this is part of what is needed. [CBC]As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. [NR] I don't understand what this means. You can say f(a,c,b) and q(a,b,c) in FOL. You can.t say f:q(a,b,c) where f:q is a tuple with the type f and the type q that would be equivalent to (f(a,c,b) and q(a,b,c)). The reason that you may want such a thing is to you could say z(k,f:q(a,b,c)). Note that I am making up a logic here while making up a way to express it, the point being . you can.t do it in FOL (as far as I know). -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 1:01 PM To: Cory Casanave Cc: Maged Elaasar; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations On May 24, 2011, at 9:28 AM, Cory Casanave wrote: Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. SPARQL allows us to make distinctions on the basis of structural equivalence. That is, the following are structurally different: case1: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) vs. case2: ObjectPropertyAssertion(Subject1, predicate1, Object1) vs. case3: ObjectPropertyAssertion(Subject1, predicate2, Object1) Structurally, we can also use SPARQL to find out whether there is a direct or indirect generalization relationship between predicate1 and predicate2. Of course, if we turn on OWL2 DL semantics and if the ontology is consistent, then we can use a reasoner to answer questions about which link(s) are consistent; somewhat independently of whether the links have been asserted explicitly (e.g. case1) or not (e.g., case2 and 3) according to the generalization relationships that can be inferred or have been explicitly asserted between predicate1 and predicate2. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. Yes, yes, yes!!! My point is that we have *no* identity at all for links that are classified by associations in any CMOF metamodel because the MOF2/XMI mapping specification does not represent instances of such associations in a form that has a an XMI identity we could refer to. In Steve's example, any link that is classified by the meta-association UML::A_nestedClassifier_class has no XMI identity at all. Therefore, it is impossible to conceive of having a link that would be classified by an association defined in a profile where that association would be a specialization of UML::A_nestedClassifier_class. This is the fundamental limitation we have that makes meta-associations second-class citizens in our current metamodeling architecture. The explanation is simple: UML is a CMOF metamodel but all of the serializations of *instances* of a UML model are subject to the EMOF limitations of the MOF2/XMI mapping. There are ways to fix this problem: a) change all associations in UML to have all of the ends owned by the association itself. This means that the CMOF UML metamodel would map into XML schemas and XML documents where instances of meta-associations would have XMI identity (see clause 6.5.3 in XMI2.1/2.1.1 and 6.4.3 in XMI2.4) b) make all associations in UML AssociationClasses instead of Association + fix the CMOF mapping rules to ensure that instances of AssociationClass in a CMOF metamodel map according to the rules for Class. That is, fix the *intent* in XMI2.4 where *all* associations, regardless of association end ownership, map to elements that have XMI identity. We still have to fix the CMOF mapping rules to make sure that an AssociationClass is mapped according to the EMOF rules for Classes. We still have to verify that the class-owned association ends are mapped in a sensible way. There may be other options. Regardless of which option is used, it's clear that there would be a difference in using EMOF-based XMI serialization vs. true CMOF-based XMI serialization. In the former, instances of meta-associations have no XMI identity at all; in the latter, they do and therefore become first-class entities we could further specialize. Independently of this, we would have to fix some OCL minutiae w.r.t. the definition of conformsTo() so that we could do subsets, redefinitions and generalizations across an extension boundary; something that we can't do currently. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. I don't understand what this means. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. Can't answer this because I don't understand what you are saying. - Nicolas. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies toA_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif> From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "Cory Casanave" , Maged Elaasar , "Ed Seidewitz" , Elisa Kendall , "Pete Rivett - Adaptive" , "smof-ftf@omg.org" Subject: RE: SMOF does not implement dynamic classification of associations Thread-Topic: SMOF does not implement dynamic classification of associations Thread-Index: AcwQuiqsyhJX6FPWSfa/fx19nUAC6wALnK+AABhatBAADcohsAE8eugAALYnkuAAEqovgAAAHyQAAAAX/oAABIR7AAAAXbqAAAKO6AAAFuDngAABzaOAAABtFIAAAxhLAAAAWbUAAAEmcgAAAZ1cAAABB06ADE/xxeA= Date: Tue, 26 Jul 2011 10:00:08 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] I am resuscitating this thread from May because it is time for us to decide whether we can resolve issue 16233 in the SMOF FTF, which has to complete by the next meeting, i.e. a resolution has to be formulated in the next week or two. Implementing dynamic classification of associations in SMOF would be a large piece of work; particularly it requires major upheaval in the Semantics section. Every link would need to have multiple slots at either end, and a load of constraints to ensure that all of the slots at each end have the same value. The notion of .opposite. slot would need to be substantially modified. Several questions remain unanswered in my mind. Is it possible to multiply classify a composition with a non-composition? Is it possible to multiply classify a composition with a composition in the other direction? If one or more of the classifying associations has properties which are derived and/or navigable and/or class-owned, what are the restrictions on multiple classification? What about association end subsetting and redefinition? Can the notions of compatibility or incompatibility be wholly or partially derived? What is the impact on XMI serialization? Given the problems we had coming up with a satisfactory interpretation of MOF semantics to resolve the recent urgent issue on how to serialize StructuredActivityNode, I am very nervous about being able to answer these questions in a satisfactory way. This is technically very tricky and I feel that a correct solution is out of my reach without investing a disproportionate amount of time and energy: I would have to build a working prototype, and I don.t have time or resources to do that. My inclination, therefore, is to defer this issue. If at some future date this turns out to be a real practical requirement, I would suggest it is resolved in an SMOF 2.0 which might by that stage be able to build on more clearly formulated MOF semantics. I.m happy to entertain other views, and if somebody wants to volunteer a resolution I am happy to review it. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 May 2011 19:17 To: Cory Casanave Cc: Maged Elaasar; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Cory, The conversion from Association to AssociationClass is trivial to do in QVTO. The tricky part is the MOF/XMI mapping. In effect, this is the kind of issue where the only way to get confidence that the fix will work is to prototype it. Pete had asked me whether I could help developing a QVTO prototype of the mapping rules. Until recently, there hasn't been a significant business case for it but this issue may change that because at JPL, it would be very useful for us to have a true CMOF UML2.4 metamodel where we can do true semantic specialization of the UML metamodel in domain-specific profiles. I would like to know if vendors would be interested in exploring this further and perhaps supporting this effort. - Nicolas. On May 24, 2011, at 10:47 AM, Cory Casanave wrote: Nicolas, I think we are getting down to the real need . that we want to have associations as .first class. and be able to use these associations as arguments in other associations. This is essential to supporting a .fact based. approach, such as what they do in the IDEAS framework. Once you do this then associations are .instances. and you want those instances to be able to have multiple types for the same reason as all the other SMOF multiple classifications. The UML lens on this would be as you say . that association classes are the representation of these .facts.. This end ownership thing is and, in my opinion, always has been baloney. The .ends. are part of the .semantic cluster. that is the association (each end and sometimes other links are derivatives of the fundamental fact being asserted). .End ownership. is an implementation concern, not an architectural one. Now, I have questions as to the wisdom of pushing MOF this far in places where other things already stand . but if you want MOF to compete in the world of semantic description, this is part of what is needed. [CBC]As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. [NR] I don't understand what this means. You can say f(a,c,b) and q(a,b,c) in FOL. You can.t say f:q(a,b,c) where f:q is a tuple with the type f and the type q that would be equivalent to (f(a,c,b) and q(a,b,c)). The reason that you may want such a thing is to you could say z(k,f:q(a,b,c)). Note that I am making up a logic here while making up a way to express it, the point being . you can.t do it in FOL (as far as I know). -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 1:01 PM To: Cory Casanave Cc: Maged Elaasar; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations On May 24, 2011, at 9:28 AM, Cory Casanave wrote: Nicolas, That is not the same thing . that is 2 independent assertions that happen to have the same subject & object. You can.t have one .triple. with 2 predicates. Now, if you are arguing that they would be semantically equivalent, that is possible and something to think about. But as we all know being semantically equivalent and structurally equivalent are not the same thing at all. SPARQL allows us to make distinctions on the basis of structural equivalence. That is, the following are structurally different: case1: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) vs. case2: ObjectPropertyAssertion(Subject1, predicate1, Object1) vs. case3: ObjectPropertyAssertion(Subject1, predicate2, Object1) Structurally, we can also use SPARQL to find out whether there is a direct or indirect generalization relationship between predicate1 and predicate2. Of course, if we turn on OWL2 DL semantics and if the ontology is consistent, then we can use a reasoner to answer questions about which link(s) are consistent; somewhat independently of whether the links have been asserted explicitly (e.g. case1) or not (e.g., case2 and 3) according to the generalization relationships that can be inferred or have been explicitly asserted between predicate1 and predicate2. By your argument MOF allows the same thing . you can have 2 independent links between the same instances, each with its own association type. Perhaps the only real difference is then in lifecycle management and identity. Once you can use an association link as in another tuple the identity becomes very important and you may want multiple classification for the same reasons you want it for anything else. Yes, yes, yes!!! My point is that we have *no* identity at all for links that are classified by associations in any CMOF metamodel because the MOF2/XMI mapping specification does not represent instances of such associations in a form that has a an XMI identity we could refer to. In Steve's example, any link that is classified by the meta-association UML::A_nestedClassifier_class has no XMI identity at all. Therefore, it is impossible to conceive of having a link that would be classified by an association defined in a profile where that association would be a specialization of UML::A_nestedClassifier_class. This is the fundamental limitation we have that makes meta-associations second-class citizens in our current metamodeling architecture. The explanation is simple: UML is a CMOF metamodel but all of the serializations of *instances* of a UML model are subject to the EMOF limitations of the MOF2/XMI mapping. There are ways to fix this problem: a) change all associations in UML to have all of the ends owned by the association itself. This means that the CMOF UML metamodel would map into XML schemas and XML documents where instances of meta-associations would have XMI identity (see clause 6.5.3 in XMI2.1/2.1.1 and 6.4.3 in XMI2.4) b) make all associations in UML AssociationClasses instead of Association + fix the CMOF mapping rules to ensure that instances of AssociationClass in a CMOF metamodel map according to the rules for Class. That is, fix the *intent* in XMI2.4 where *all* associations, regardless of association end ownership, map to elements that have XMI identity. We still have to fix the CMOF mapping rules to make sure that an AssociationClass is mapped according to the EMOF rules for Classes. We still have to verify that the class-owned association ends are mapped in a sensible way. There may be other options. Regardless of which option is used, it's clear that there would be a difference in using EMOF-based XMI serialization vs. true CMOF-based XMI serialization. In the former, instances of meta-associations have no XMI identity at all; in the latter, they do and therefore become first-class entities we could further specialize. Independently of this, we would have to fix some OCL minutiae w.r.t. the definition of conformsTo() so that we could do subsets, redefinitions and generalizations across an extension boundary; something that we can't do currently. As far as I know, no FOL allows a .single- tuple to be described by more than one predicate type. I don't understand what this means. The choice is . do we want to carry that restriction over to SOMF? I have some idea why the restriction is part of FOL but would defer to those deep into the reasons why FOL is the way it is. Can't answer this because I don't understand what you are saying. - Nicolas. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 24, 2011 12:18 PM To: Maged Elaasar Cc: Cory Casanave; Ed Seidewitz; Elisa Kendall; Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: Re: SMOF does not implement dynamic classification of associations Maged, On May 24, 2011, at 7:49 AM, Maged Elaasar wrote: Nic, I was trying to make a point that OWL does not support triples have multiple explict predicates at the same time. The notation or predicate1/predicate2 I used was my attempt to communicate this point, of course it is not a standard notation since as I said it is not allowed. I disagree; OWL2 can do this: ObjectPropertyAssertion(Subject1, predicate1, Object1) ObjectPropertyAssertion(Subject1, predicate2, Object1) This is true of any conforming serialization of an OWL2 ontology because the OWL2 canonical parsing procedure requirement applies to any conforming serialization of an OWL2 ontology. - Nicolas. Can you show me how OWL have an equivalent of a link with multiple explicit assocations? I am not talking about implicit ones achieved through property subsetting. Maged "Rouquette, Nicolas F (313K)" "Rouquette, Nicolas F (313K)" 05/24/2011 10:37 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Elisa Kendall , Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , "smof-ftf@omg.org" , Steve Cook Subject Re: SMOF does not implement dynamic classification of associations Maged, Respectfully, this is *not* the point of this discussion. This discussion is about an association A1 defined in a profile as a *specialization* of an association A2 defined in a metamodel. Assuming that we are *not* using MOF2/XMI (any flavor), then we can have several situations: a) The model is initially constructed with a link L classified by A2. Now, we also want to classify L as an instance of A1 as well. If we assume that a link is really an InstanceSpecification whose classifier is an Association, there is no problem in UML. b) The model is initially constructed with a link L classified by A1. By the semantics of A1 => A2 generalization, L is also classified by A2. This discussion is only one of several issues surrounding the current UML profile mechanism. One of the really fundamental limitations of this mechanism comes from the fact that there as never been any true CMOF serialization of the UML metamodel in XMI because there are no rules in any version of the MOF2/XMI mapping specification that apply to map the CMOF associations in the UML metamodel in a schema production or element production. Therefore, we have been working with only EMOF-based implementations of the CMOF UML metamodel. IN that context, this explains why CMOF associations in the UML metamodel are second-class citizens -- in fact, they are not there at all as far as XMI is concerned. Until we repair this flaw, it will be very difficult to define an extension mechanism where *any* classifier defined in a metamodel can be extended. Making any kind of expressiveness claims about OWL in this regard is difficult because such claims depend on how UML associations are mapped into OWL. There are several mapping strategies! Before attempting to make comparisons about OWL's expressiveness, I would encourage you to read the OWL2 functional specification. It's the *only* normative specification for the *abstract syntax* of OWL2. This particular specification defines only *one* construction operation: http://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions A positive object property assertion ObjectPropertyAssertion( OPE a1 a2 ) states that the individual a1 is connected by the object property expression OPE to the individual a2. ObjectPropertyAssertion := 'ObjectPropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')' Until you explain what your notation means in terms of normative construction operations defined for OWL2, the interpretation of your distinction is completely subjective: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 Also please note that RDF is used for two very different purposes in OWL: - as a serialization for OWL - as a semantics for OWL The RDF semantics for OWL does not provide any kind of *construction* operation at all! Using RDF-based serialization for OWL to make assertions about the expressiveness of OWL is also silly. The reason is that *any* kind of serialization of an ontology -- RDF, tuples, N3, ... -- is subject to the same *normative* canonical parsing procedure: http://www.w3.org/TR/owl2-syntax/#Canonical_Parsing_of_OWL_2_Ontologies In practice, I find it easier to use the OWL2 functional specification because it specifies the complete set of constructors we can use to create any well-formed OWL2 ontology. With RDF, it is unfortunately easy to dismiss the canonical parsing procedure requirement and make invalid claims about the expressiveness of OWL2. Finally, note that there are really 3 levels of expressiveness one can consider with OWL: - OWL2 DL - OWL2 Full - OWL2 Annotations. OWL2 DL is the most restrictive subset. Note that even though DL is restrictive, OWL2 has one significant expressiveness improvement over OWL1: OWL2 *allows* the same entity IRI to designate all at once: - an OWL2 Class; - an OWL2 Property (one of Object, Data or Annotation) - an OWL2 Individual That's quite a wallop! Sometimes, I find it difficult to think through the implications of what can be done with this much expressiveness because we have not had anything similar to this in UML except for the concept of UML::AssociationClass that, unfortunately, is out of scope for CMOF. If we had UML::AssociationClass in CMOF2.4, we could easily fix the UML profiles as I've described in my revised Metamodel Extension RFP. OWL2 Full is more expressive than that. OWL2 Annotations is even more expressive; there are really no restrictions in terms of the levels of circularity, self-reference, reflection, reification, etc.. - Nicolas. On May 24, 2011, at 6:45 AM, Maged Elaasar wrote: As Cory said, defining a property to be a subset of multiple properties is already supported in MOF as well as in OWL. What we are discussing here is defining a single triple with multiple predicates between the subject and the object, i.e., some thing like the following: Subject1 predeicate1/predicate2 Object1 vs. Subject1 predeicate1 Object1 Subject1 predeicate2 Object1 I believe the former, i.e., a triple (which is like a link in MOF) with two predicates (which is like classified by two associations in MOF), is not supported in OWL. Maged Elisa Kendall Elisa Kendall 05/23/2011 10:50 PM To Cory Casanave cc "Rouquette, Nicolas F (313K)" , Steve Cook , Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett - Adaptive , smof-ftf@omg.org, Ed Seidewitz Subject Re: SMOF does not implement dynamic classification of associations Hi Cory, I guess the thing that I'm having trouble understanding is whether you're talking about a single occurrence of a particular triple in a given document, or the higher level model that it is part of. With respect to the OWL API, you have to use punning (say, for a property defined as an annotation property in one place and a data property elsewhere), but I'm not sure you're asking for that case. If you're talking about a property in an inheritance hierarchy that is an object property defined to have multiple parent properties, and now I want to ask the question, "what are the classifiers for this property", what you see in Protege makes it appear that multiple classification is supported. If you can let me know whether you're talking about the punning example or the latter case, I will drop PFPS a note to see if he can clarify further, as needed. For CL, the questions are whether or not a functional term can be multiply classified, and whether or not the term that is acting in the role of a predicate for a particular atomic sentence can be multiply classified (related to the diagram you've identified, but a different question I think). Hopefully I'll be able to get a few answers shortly, Elisa On 5/23/2011 6:37 PM, Cory Casanave wrote: Elisa, No problem with being a subproperty of multiple properties, I have done that. The issue at hand is a tripe (or predicate in CL) being an . instance of. more than one property. Subproperty of multiple properties is the same as .multiple inheritance. not multiple classification. As for punning, sure you can hack around these things but there is no direct representation. At least in RDF, there is only one .p. slot. As for CL, I.m not as sure, but note the .1. in predicate from the CL spec: -Cory From: Elisa Kendall [mailto:ekendall@sandsoft.com] Sent: Monday, May 23, 2011 9:27 PM To: Cory Casanave Cc: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Hi Cory, Are you sure about RDF/OWL? In OWL 2, a particular property can participate in many subproperty axioms, including being a subproperty of a complex property chain. For example, from the OWL 2 functional spec, the following would be interpreted as "The sister of someone's mother is that person's aunt." SubObjectPropertyOf ( ObjectPropertyChain ( a:hasMother a:hasSister ) a:hasAunt ) I took a look at the direct semantics specification, and saw nothing that would lead me to believe that a particular property cannot be a subproperty of multiple properties, only that a given subproperty axiom takes two arguments. Some of the property axioms can actually be defined via multiple inheritance, including those pesky axioms that we created the ugly work-arounds for in ODM. If you're talking about predicates as "instances of properties", which might correspond to links in UML, then I would argue that you can still do this in OWL via punning ... although it's clumsy. Similarly for CL, I don't recall any limitation on the number of such relationships a given function or relation can participate in. There may be limits on relation inheritance for specific dialects of CL, but not on the language in its most general form, and there were none that I recall in KIF. Thanks, Elisa On 5/23/2011 4:17 PM, Cory Casanave wrote: Ok, more typos than usual! I think I am fried for today! From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: Monday, May 23, 2011 7:15 PM To: Rouquette, Nicolas F (313K); Steve Cook; Maged Elaasar Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: RE: SMOF does not implement dynamic classification of associations I agree with Nicolas on the usefulness of multiple classification of associations. Another .simplifying. reson is that association classification is just another kind of classification hand having these features available for some but not all classifications is confusing. I would note, however, that OWL/RDF and (I think) Common Logic do not allow for multiple classification of predicates. So we would be breaking some new ground. -Cory From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 23, 2011 7:12 PM To: Steve Cook; Maged Elaasar Cc: Cory Casanave; Pete Rivett - Adaptive; smof-ftf@omg.org; Ed Seidewitz Subject: Re: SMOF does not implement dynamic classification of associations Steve, Maged: Note: I'm against removing the multiple classification requirement for associations in requirement 6.5.2 of the Metamodel Extension RFP. This requirement is important because it addresses one of the major limitations of the current UML profile mechanism where we cannot do something like this: <> extends UML::Class <> extends UML::Class <> extends UML::A_nestedClassifier_class (this kind of domain-specific use of the UML cannot be specified in the current UML profile mechanism) It's the last part that causes a problem as Steve explained for his example. What I can do is the following: Package P; <> P::Jack; <> P::Fido; Then, if I want to say that P::Fido has another role as Jack's house pet, I can do so like this: <> P::Jack::Fido { specializes <> P::Fido } The instance of UML::A_nestedClassifier_class in my model between P::Jack and P::Jack::Fido is an element that is currently out of bounds of what we can access in a UML modeling tool and definitely out of bounds of what we can specialize with a UML profile. It might make sense to try: <> extends UML::Association THis would presume the fact that we could somehow apply this stereotype to the instance of the UML::A_nestedClassifier_class association between P::Jack and P::Jack::Fido. This is clearly not possible. I think this issue goes at the core of the principles we've used for constructing metamodels and for specifying what it means to instantiate them. It's in fact the latter that is unclear as far as associations are concerned. This problem has nothing to do with the organization per se of the UML metamodel; it's an intrinsic issue with our metamodeling architecture; one that I really hope this particular Metamodel Extension RFP will focus on and tackle. If we can find a way to make progress in this area, this could make extending the UML metamodel a lot more sensible and relevant in practice. - Nicolas. On May 23, 2011, at 7:48 AM, Steve Cook wrote: Maged Well, the motivation for this issue came from Nicolas (who I am including in this thread even though he.s not on the SMOF FTF; and I am also including Ed because he knows about this kind of stuff ;) Nic suggested that multi-classification of links is a requirement for the metamodel extension facility RFP. I am somewhat persuaded by this, but still need to convince myself properly. I think this is a very complicated and non-obvious matter. Here are some reflections on it. 1. What does MOF 2.4 say about this? In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF seems to be silent on the semantics of association generalization. 2. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: .Each instance of the specific classifier is also an indirect instance of the general classifier.. 3. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. 4. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. 5. But I think there is a problem in fact. Let.s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval, despite what UML says. That does give some anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. 6. Let.s assume then that we fix the MOF semantics so that it handles association specialization correctly. This leads us inexorably to having the same link classified by multiple associations. Although there are no examples in the UML metamodel, there is nothing to stop the metamodeller creating an association-owned end that redefines more than one end in the same context, where those ends belong to different . unrelated - associations. A link of that redefining association will then necessarily be an instance of all of its generalizations. 7. In MOF I cannot see a user rationale for multiply classifying a link by unrelated associations for cases other than the ones described above. With regard to property navigations, you.d get the same answers both ways. Only by using CMOF reflection for operations that understand link identity would there be any perceptible differences, and I do not know what a user would do with those differences. 8. In SMOF things are different. If you go back to my CatEatsDog example below, let.s say I want the circle-cross notation that currently applies toA_nestedClassifier_class also to apply to CatEatsDog. Said another way, I want MyDog to appear in the nestedClassifier property for MyCat. Well, it already appears in the eatenDog property, but there is no SMOF mechanism to make it simultaneously appear in the nestedClassfier property. I could make Cat a subclass of Class, and Dog a subclass of Classifier, and CatEatsDog a subclass of A_nestedClassifier_class, and then it would appear in the nestedClassifier property if MOF were fixed (or in fact I could just make eatenDog subset nestedClassifier): but that is a very big restriction on my Animals metamodel, because I want it to be independent of UML. Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2011 00:22 To: Cory Casanave Cc: Pete Rivett - Adaptive; smof-ftf@omg.org; Steve Cook Subject: RE: SMOF does not implement dynamic classification of associations Steve, I am not sure I see why it is necessary to have one link multi-classified by two associations vs. two links, each classified by one association? What if the original model has 5 associations between two classes A and B, would you create one link possible typed by 5 associations vs. creating possibly 5 links (as we do today)? Is there a rationale for both cases? Maged "Cory Casanave" "Cory Casanave" 05/13/2011 11:23 AM To "Steve Cook" , "Pete Rivett - Adaptive" cc Subject RE: SMOF does not implement dynamic classification of associations Steve, I agree with your assessment of the limitation. I vaguely remember a discussion where the multiple classification was originally on type and moved to class to limit the capability. I would support all instanced (of anything) being able to be classified by multiple types. This seems like a reasonable FTF change. -Cory From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 13, 2011 4:58 AM To: Pete Rivett - Adaptive Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations Pete In my example, A is an instance of mof::Association. It is an association in a metamodel, not an association in a UML model. Let.s say, to be concrete, that it is A_nestedClassifier_class, and C1 is uml::Class, and C2 is uml::Classifier. We then create a UML profile for animals, and we create metaclasses Dog and Cat, and an association between them CatEatsDog. We then create a UML model with a uml::Class MyDog, multiply classified as Dog, and another uml::Class MyCat, multiply classified as Cat; we make MyDog nested in MyCat; and we multiply classify the link that instantiates A_nestedClassifier_class by CatEatsDog. SMOF does not allow this. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 May 2011 22:16 To: Steve Cook Cc: smof-ftf@omg.org Subject: RE: SMOF does not implement dynamic classification of associations I don.t think so: in a UML model everything is an instance of a MOF metaclass including associations. In your example A is an instance of the MOF metaclass uml:Association. Crucially, uml:Association is an instance of MOF:Class not MOF:Association. A can therefore additionally be classified with the MOF metaclass B (representing what is currently modeled as a Stereotype extending uml:Association). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 12, 2011 8:38 AM To: issues@omg.org Cc: smof-ftf@omg.org Subject: SMOF does not implement dynamic classification of associations SMOF restricts itself to dynamically classifying elements, and requires links to have a single static Association. The problem with that will show up as soon as we want to use SMOF for profiles. We might, for example, have metaclasses C1 and C2 connected by an association A. Apply the profile and it automatically infers that C1 needs also to be classified by P1 and C2 by P2 . and A by B. But SMOF doesn.t allow the .A by B. part. -- Steve <14636486.gif>