Issue 13870: Question on InvertibleAttribute subclass of ExplicitAttribute (express-rtf) Source: TopQuadrant (Mr. David Price, dprice(at)topquadrant.com) Nature: Uncategorized Issue Severity: Summary: It seems an odd thing to me to create a subclass of ExplicitAttribute to instantiate for Attributes that have the potential to have inverses. I don't understand the rationale. Seems like it would be simper to have a constraint on InverseAttribute about it being owned by an EntityType referenced in an ExplicitAttribute Resolution: Revised Text: Actions taken: April 16, 2009: received issue Discussion: End of Annotations:===== ce: 150067498/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$F2S-NILDRAM-ACCEPTED/f2s-nildram-customers/84.12.98.161/None/david.price@eurostep.com X-SBRS: None X-RemoteIP: 84.12.98.161 X-IP-MAIL-FROM: david.price@eurostep.com X-SMTP-AUTH: X-MUA: KMail/1.9.10 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAL/W5klUDGKh/2dsb2JhbACBU79+CY9egkqBMwY X-IronPort-AV: E=Sophos;i="4.40,198,1238972400"; d="scan'208";a="150067498" X-IP-Direction: IN From: David Price Organization: Eurostep To: express-ftf@omg.org Subject: Question on InvertibleAttribute subclass of ExplicitAttribute Date: Thu, 16 Apr 2009 15:00:23 +0100 User-Agent: KMail/1.9.10 All, Before submitting a formal issue, I was wondering if everyone else understands InvertibleAttribute? It seems an odd thing to me to create a subclass of ExplicitAttribute to instantiate for Attributes that have the potential to have inverses. I don't understand the rationale. Seems like it would be simper to have a constraint on InverseAttribute about it being owned by an EntityType referenced in an ExplicitAttribute. Thoughts? David -- Mobile +44 7788 561308 UK +44 2087473900 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Date: Thu, 16 Apr 2009 11:16:27 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: David Price CC: express-ftf@omg.org Subject: Re: Question on InvertibleAttribute subclass of ExplicitAttribute X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3GFGV6H010502 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240499793.40023@S+17bNdAtWgzPPUffmuQUA X-Spam-Status: No David Price wrote: Before submitting a formal issue, I was wondering if everyone else understands InvertibleAttribute? It seems an odd thing to me to create a subclass of ExplicitAttribute to instantiate for Attributes that have the potential to have inverses. I don't understand the rationale. Seems like it would be simper to have a constraint on InverseAttribute about it being owned by an EntityType referenced in an ExplicitAttribute. Thoughts? I take the blame for creating it. The reason was that it makes it possible to model Relationships in a way that makes sense. InvertibleAttributes establish Relationships; other ExplicitAttributes don't. The problem is precisely the complexity of the "constraint on InverseAttribute". The datatype of the ExplicitAttribute must be one of: the entity type, a select type that contains the entity type in the select list, or an aggregate type whose member-type is either of the above. So, the relationship between the InvertibleAttribute and the entity type that has the INVERSE isn't 'attribute-type'; it is 'some appropriate element of the attribute-type'. In the OWL style, it is useful to define a class that has those properties, and then we can define the 'some appropriate element of the attribute-type' property for that class. I would argue that Part 11 has both of these concepts; it just doesn't have terms for them. The InvertibleAttribute concept is unnecessary if you don't need to model Relationship. You don't need Relationship to map to OWL, because it only has directed properties. But you do need it to map to UML bi-directional Association. What I suspect David is concerned about is that EXPRESS and UML tools don't have the OWL view that an ExplicitAttribute can be discovered to be an InvertibleAttribute if an INVERSE is created. They have the object-oriented view that a thing IS whatever it is DECLARED to be, and all of its classifications follow from the declaration, which necessitates "leaf classification" a priori. So the parser is required to employ the "invertibility rule" on encountering the declaration of the explicit attribute, rather than just testing for its satisfaction when an INVERSE is declared. [I would go so far as to say this is a CIM/PIM kind of thing: the conceptual model has a classifier whose characteristics are the properties that satisfy the rule; the software engineering model might not have such a classifier. The same kind of idea applies to the GeneralizedType v. ActualType stuff, and to the Expression v. VARExpression stuff, except that in both of those cases, the semantics of the same syntax is different. In this case, the semantics of the InvertibleAttribute is implicit in the semantics of ExplicitAttribute.attribute-type. The InvertibleAttribute only makes that semantics explicit. It is a weakness of mine that I want to model semantics as formally as possible. The relationship model is a case in point. But the truly bizarre case is the effort to explain the relationships between ActualTypes and the GeneralizedTypes of formal parameters. I have tried three times, and the current text suggests that a better alternative would have been "then a miracle occurs" -- it is no less comprehensible. So perhaps it would be better to find an alternative formalization of this kind of thing, and not try to do it in MOF-cum-OCL.] -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Trace: 94217587/mk-outboundfilter-6.mail.uk.tiscali.com/F2S/$F2S-NILDRAM-ACCEPTED/f2s-nildram-customers/84.12.98.161/None/david.price@eurostep.com X-SBRS: None X-RemoteIP: 84.12.98.161 X-IP-MAIL-FROM: david.price@eurostep.com X-SMTP-AUTH: X-MUA: KMail/1.9.10 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAK4X50lUDGKh/2dsb2JhbACBU8AwCY9wgkqBMwY X-IronPort-AV: E=Sophos;i="4.40,199,1238972400"; d="scan'208";a="94217587" X-IP-Direction: IN From: David Price Organization: Eurostep To: express-ftf@omg.org Subject: Re: Question on InvertibleAttribute subclass of ExplicitAttribute Date: Thu, 16 Apr 2009 18:39:43 +0100 User-Agent: KMail/1.9.10 Thanks Ed. A few comments below. On Thursday 16 April 2009 16:16:27 Ed Barkmeyer wrote: > David Price wrote: > > Before submitting a formal issue, I was wondering if everyone else > > understands InvertibleAttribute? > > > > It seems an odd thing to me to create a subclass of ExplicitAttribute to > > instantiate for Attributes that have the potential to have inverses. I > > don't understand the rationale. Seems like it would be simper to have a > > constraint on InverseAttribute about it being owned by an EntityType > > referenced in an ExplicitAttribute. > > > > Thoughts? > > I take the blame for creating it. The reason was that it makes it > possible to model Relationships in a way that makes sense. > InvertibleAttributes establish Relationships; other ExplicitAttributes > don't. > > The problem is precisely the complexity of the "constraint on > InverseAttribute". The datatype of the ExplicitAttribute must be one of: > the entity type, a select type that contains the entity type in the > select list, or an aggregate type whose member-type is either of the > above. So, the relationship between the InvertibleAttribute and the > entity type that has the INVERSE isn't 'attribute-type'; it is 'some > appropriate element of the attribute-type'. In the OWL style, it is > useful to define a class that has those properties, and then we can > define the 'some appropriate element of the attribute-type' property for > that class. I would argue that Part 11 has both of these concepts; it > just doesn't have terms for them. I agree in principle, but have a couple of issues. > > The InvertibleAttribute concept is unnecessary if you don't need to > model Relationship. You don't need Relationship to map to OWL, because > it only has directed properties. But you do need it to map to UML > bi-directional Association. This, I don't understand. UML bi-directional associations cannot be represented properly in EXPRESS. You have to choose one of the entity types to own one end as an explicit attribute and the other is left to be an inverse. Am I missing something? > > What I suspect David is concerned about is that EXPRESS and UML tools > don't have the OWL view that an ExplicitAttribute can be discovered to > be an InvertibleAttribute if an INVERSE is created. They have the > object-oriented view that a thing IS whatever it is DECLARED to be, and > all of its classifications follow from the declaration, which > necessitates "leaf classification" a priori. So the parser is required > to employ the "invertibility rule" on encountering the declaration of > the explicit attribute, rather than just testing for its satisfaction > when an INVERSE is declared. This is indeed most of my concern. Pity this metamodel isn't written using OWL, but as it's MOF we have this problem. It's also a question of "invertible" vs. "inverted" and which you mean. Also - as I understand things, it's also possible that whether an ExplicitAttribute is invertible or not can be on a per-instance basis. TYPE s = REAL; END_TYPE; TYPE sel = SELECT (s, e); END_TYPE; ENTITY e; END_ENTITY; ENTITY e1: a : sel; END_ENTITY; If SelectType 'sel' has a SpecializationType 's' and an EntityType 'e' in it's select list, and an EntityType 'e1' has an explicit attribute 'a' referencing 'sel', then you can say that 'a' is always an InvertibleAttribute. What would I do in the metamodel in this case? > > [I would go so far as to say this is a CIM/PIM kind of thing: the > conceptual model has a classifier whose characteristics are the > properties that satisfy the rule; the software engineering model might > not have such a classifier. The same kind of idea applies to the > GeneralizedType v. ActualType stuff, and to the Expression v. > VARExpression stuff, except that in both of those cases, the semantics > of the same syntax is different. In this case, the semantics of the > InvertibleAttribute is implicit in the semantics of > ExplicitAttribute.attribute-type. The InvertibleAttribute only makes > that semantics explicit. Agree it's more explicit, but as I mentioned it's harder to implement and doesn't seem to cover all cases easily if my example above is valid. > > It is a weakness of mine that I want to model semantics as formally as > possible. The relationship model is a case in point. But the truly > bizarre case is the effort to explain the relationships between > ActualTypes and the GeneralizedTypes of formal parameters. I have tried > three times, and the current text suggests that a better alternative > would have been "then a miracle occurs" -- it is no less comprehensible. > So perhaps it would be better to find an alternative formalization > of this kind of thing, and not try to do it in MOF-cum-OCL.] I'm happy it's you working on that miracle, rather than me. > > -Ed -- Mobile +44 7788 561308 UK +44 2087473900 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ Date: Thu, 16 Apr 2009 16:44:46 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: David Price CC: express-ftf@omg.org Subject: Re: Question on InvertibleAttribute subclass of ExplicitAttribute X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3GKioQu023450 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240519491.43256@8qEsuoUvdx8FhaUsCdXKtw X-Spam-Status: No OK. Since we are discussing it, it is clearly an Issue. I wrote: The InvertibleAttribute concept is unnecessary if you don't need to model Relationship. You don't need Relationship to map to OWL, because it only has directed properties. But you do need it to map to UML bi-directional Association. David wrote: This, I don't understand. UML bi-directional associations cannot be represented properly in EXPRESS. You have to choose one of the entity types to own one end as an explicit attribute and the other is left to be an inverse. Am I missing something? Ah. I was considering whether EXPRESS "relationships" can be properly represented in UML (not the other way around). If the EXPRESS model contains an explicit attribute and exactly the obvious INVERSE for it, as is the case in the MRMs of many SC4 "modules", the pair maps to a single UML association. If the EXPRESS model contains multiple INVERSE attributes in different subtypes of the nominal range entity type, the UML model would have to include specializations of a common association, at best. In this way, we lose the EXPRESS notion that the explicit attribute in a Relationship is somehow "more significant" than the inverse attribute. In practice that distinction is usually a PSM stereotype. And that is, in fact, exactly how I would capture that distinction in UML -- by stereotyping the inverse association end. Now, if the UML association is being translated to EXPRESS, the mapping to EXPRESS must indeed choose one association end as explicit and the other as inverse, which gains some presumptive semantics that was not in the UML model. The question is what we presume that semantics is. It is not clear to me that Part 11 supplies any semantic interpretation for that choice. It is only the Part 2x PSM interpretations that do. And the Part 21 choice has no semantic significance. For example, the STEP practice of modeling mandatory dependence by a single-valued explicit attribute of the child clearly models a UML Composite association. But in EXPRESS it forces the owning entity to have the inverse attribute. Part 22 implementations often need to add these inverses to get the desired implementation. And if we apply the Part 28 containment mapping, we end up with the employee containing the organization. So I am very uncomfortable about assigning semantics to explicit v. inverse. (The Gang of Four were modeling in SQL using EXPRESS, and that PSM bias doesn't translate well to Java and XML.) What I suspect David is concerned about is that EXPRESS and UML tools don't have the OWL view that an ExplicitAttribute can be discovered to be an InvertibleAttribute if an INVERSE is created. They have the object-oriented view that a thing IS whatever it is DECLARED to be, and all of its classifications follow from the declaration, which necessitates "leaf classification" a priori. So the parser is required to employ the "invertibility rule" on encountering the declaration of the explicit attribute, rather than just testing for its satisfaction when an INVERSE is declared. This is indeed most of my concern. Pity this metamodel isn't written using OWL, but as it's MOF we have this problem. Yeah, well. That's what SMOF is about. It's also a question of "invertible" vs. "inverted" and which you mean. Also - as I understand things, it's also possible that whether an ExplicitAttribute is invertible or not can be on a per-instance basis. TYPE s = REAL; END_TYPE; TYPE sel = SELECT (s, e); END_TYPE; ENTITY e; END_ENTITY; ENTITY e1: a : sel; END_ENTITY; If SelectType 'sel' has a SpecializationType 's' and an EntityType 'e' in it's select list, and an EntityType 'e1' has an explicit attribute 'a' referencing 'sel', then you can say that 'a' is always an InvertibleAttribute. What would I do in the metamodel in this case? e1.a is an InvertibleAttribute. e can have an InverseAttribute; it doesn't happen to, but some subtype defined in another schema may. s and sel cannot have any Attribute. Whether an Attribute is "invertible" can be determined from the schema in which it is declared. Whether it is "inverted" depends on the schemas in which the EntityTypes of its possible values are declared. And in another sense, "inverted" is a property of what UML calls "links" in a population whose governing schema includes or interfaces the .declared-in EntityType. In this case, the semantics of the InvertibleAttribute is implicit in the semantics of ExplicitAttribute.attribute-type. The InvertibleAttribute only makes that semantics explicit. Agree it's more explicit, but as I mentioned it's harder to implement Yes. That is why I opened the question of how much detailed semantics we want to capture in the MOF constructs. and doesn't seem to cover all cases easily if my example above is valid. Your example is valid. But I believe my explanation above covers it. My point was exactly that this is something we can do to support Relationships, but it has a cost, and it is not clear how many people care. So the question is: do we want the InvertibleAttribute concept, or is it a semantic nicety that doesn't justify its cost? The floor is open. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Trace: 204474834/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$F2S-NILDRAM-ACCEPTED/f2s-nildram-customers/84.12.98.161/None/david.price@eurostep.com X-SBRS: None X-RemoteIP: 84.12.98.161 X-IP-MAIL-FROM: david.price@eurostep.com X-SMTP-AUTH: X-MUA: KMail/1.9.10 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAFvf50lUDGKh/2dsb2JhbACBTr5VCY9hgkqBMwY X-IronPort-AV: E=Sophos;i="4.40,203,1238972400"; d="scan'208";a="204474834" X-IP-Direction: IN From: David Price Organization: Eurostep To: express-ftf@omg.org Subject: Re: Question on InvertibleAttribute subclass of ExplicitAttribute Date: Fri, 17 Apr 2009 09:47:43 +0100 User-Agent: KMail/1.9.10 During the development of the SDAI spec I remember comments about it's lack of an explicit Relationship. When reviewing EXPRESS schemas, I've also often wished I had easy access to the complete set of relationships into/out of a particular entity type. Given that, if InvertibleAttribute is a pre-req to Relationship being in the metamodel, then I suppose I support leaving it as-is. Cheers, David On Thursday 16 April 2009 21:44:46 Ed Barkmeyer wrote: > OK. Since we are discussing it, it is clearly an Issue. > > I wrote: > >> The InvertibleAttribute concept is unnecessary if you don't need to > >> model Relationship. You don't need Relationship to map to OWL, because > >> it only has directed properties. But you do need it to map to UML > >> bi-directional Association. > > David wrote: > > This, I don't understand. UML bi-directional associations cannot be > > represented properly in EXPRESS. You have to choose one of the entity > > types to own one end as an explicit attribute and the other is left to be > > an inverse. Am I missing something? > > Ah. I was considering whether EXPRESS "relationships" can be properly > represented in UML (not the other way around). > > If the EXPRESS model contains an explicit attribute and exactly the > obvious INVERSE for it, as is the case in the MRMs of many SC4 > "modules", the pair maps to a single UML association. > > If the EXPRESS model contains multiple INVERSE attributes in different > subtypes of the nominal range entity type, the UML model would have to > include specializations of a common association, at best. > > In this way, we lose the EXPRESS notion that the explicit attribute in a > Relationship is somehow "more significant" than the inverse attribute. > In practice that distinction is usually a PSM stereotype. And that is, > in fact, exactly how I would capture that distinction in UML -- by > stereotyping the inverse association end. > > Now, if the UML association is being translated to EXPRESS, the mapping > to EXPRESS must indeed choose one association end as explicit and the > other as inverse, which gains some presumptive semantics that was not in > the UML model. The question is what we presume that semantics is. It > is not clear to me that Part 11 supplies any semantic interpretation for > that choice. It is only the Part 2x PSM interpretations that do. And > the Part 21 choice has no semantic significance. For example, the STEP > practice of modeling mandatory dependence by a single-valued explicit > attribute of the child clearly models a UML Composite association. But > in EXPRESS it forces the owning entity to have the inverse attribute. > Part 22 implementations often need to add these inverses to get the > desired implementation. And if we apply the Part 28 containment > mapping, we end up with the employee containing the organization. So I > am very uncomfortable about assigning semantics to explicit v. inverse. > (The Gang of Four were modeling in SQL using EXPRESS, and that PSM > bias doesn't translate well to Java and XML.) > > >> What I suspect David is concerned about is that EXPRESS and UML tools > >> don't have the OWL view that an ExplicitAttribute can be discovered to > >> be an InvertibleAttribute if an INVERSE is created. They have the > >> object-oriented view that a thing IS whatever it is DECLARED to be, and > >> all of its classifications follow from the declaration, which > >> necessitates "leaf classification" a priori. So the parser is required > >> to employ the "invertibility rule" on encountering the declaration of > >> the explicit attribute, rather than just testing for its satisfaction > >> when an INVERSE is declared. > > > > This is indeed most of my concern. Pity this metamodel isn't written > > using OWL, but as it's MOF we have this problem. > > Yeah, well. That's what SMOF is about. > > > It's also a question > > of "invertible" vs. "inverted" and which you mean. > > > > Also - as I understand things, it's also possible that whether an > > ExplicitAttribute is invertible or not can be on a per-instance basis. > > > > TYPE s = REAL; END_TYPE; > > TYPE sel = SELECT (s, e); END_TYPE; > > ENTITY e; END_ENTITY; > > ENTITY e1: a : sel; END_ENTITY; > > > > If SelectType 'sel' has a SpecializationType 's' and an EntityType 'e' in > > it's select list, and an EntityType 'e1' has an explicit attribute 'a' > > referencing 'sel', then you can say that 'a' is always an > > InvertibleAttribute. > > > > What would I do in the metamodel in this case? > > e1.a is an InvertibleAttribute. e can have an InverseAttribute; it > doesn't happen to, but some subtype defined in another schema may. > s and sel cannot have any Attribute. > > Whether an Attribute is "invertible" can be determined from the schema > in which it is declared. Whether it is "inverted" depends on the > schemas in which the EntityTypes of its possible values are declared. > And in another sense, "inverted" is a property of what UML calls "links" > in a population whose governing schema includes or interfaces the > .declared-in EntityType. > > >> In this case, the semantics of the > >> InvertibleAttribute is implicit in the semantics of > >> ExplicitAttribute.attribute-type. The InvertibleAttribute only makes > >> that semantics explicit. > > > > Agree it's more explicit, but as I mentioned it's harder to implement > > Yes. That is why I opened the question of how much detailed semantics > we want to capture in the MOF constructs. > > > and > > doesn't seem to cover all cases easily if my example above is valid. > > Your example is valid. But I believe my explanation above covers it. > > My point was exactly that this is something we can do to support > Relationships, but it has a cost, and it is not clear how many people > care. So the question is: do we want the InvertibleAttribute concept, > or is it a semantic nicety that doesn't justify its cost? > > The floor is open. > > -Ed -- Mobile +44 7788 561308 UK +44 2087473900 Skype +1 336 283 0606 Eurostep Limited. Registered in England and Wales No.03049099 Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ Date: Fri, 17 Apr 2009 11:28:12 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: David Price CC: express-ftf@omg.org Subject: Re: Question on InvertibleAttribute subclass of ExplicitAttribute X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3HFSGm5003628 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240586898.96537@kfud3vQa0dDmUP79wavYYg X-Spam-Status: No David Price wrote: During the development of the SDAI spec I remember comments about it's lack of an explicit Relationship. When reviewing EXPRESS schemas, I've also often wished I had easy access to the complete set of relationships into/out of a particular entity type. Given that, if InvertibleAttribute is a pre-req to Relationship being in the metamodel, then I suppose I support leaving it as-is. It seems to me that we agreed a year or so ago to keep Relationship in the metamodel, because many of us see its importance to various mappings. And since it is a derived concept in EXPRESS, you can add it to an M1 XMI population that only conveys the EXPRESS basics. But as I said, InvertibleAttribute is only a means of making the derivation of relationships visible in the MOF model, as distinct from making relationships visible and relegating the derivation to the text. It is not so clearly a good idea to *require* an M1 population to instantiate InvertibleAttribute, and that, I think, is the issue. I am hoping to see the opinions of other experts... -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ