Issue 17565: an instance spec should be a legitimate value of a property typed by a classifier (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: To put it simply, I'm saying this: The spec should clearly state that an instance spec is a legitimate value of a property typed by a classifier. The spec should make sure that the abstract syntax operations & constraints involving all kinds of UML classifiers & instance specifications work according to the above. The UML spec tacitly agrees with this as shown in several examples: Figure 7.54 in UML 2.4.1, page 82. Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143 Resolution: Revised Text: Actions taken: August 27, 2012: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , Ed Seidewitz , "issues@omg.org" CC: Burkhart Roger M , Sanford Friedenthal , "andrew@omg.org" , Pete Rivett , Nerijus Jankevicius Subject: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Topic: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Index: AQHNhIZnpl6QOY7RgU6czjyEQ0uMog== Date: Mon, 27 Aug 2012 19:01:45 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized To put it simply, I'm saying this: The spec should clearly state that an instance spec is a legitimate value of a property typed by a classifier. The spec should make sure that the abstract syntax operations & constraints involving all kinds of UML classifiers & instance specifications work according to the above. The UML spec tacitly agrees with this as shown in several examples: Figure 7.54 in UML 2.4.1, page 82. Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143 - Nicolas. On 8/27/12 11:11 AM, "Bock, Conrad" wrote: >Nicolas, > > > A) UML does not specify how to represent M0 instances using M1 >elements. > > > > B) UML explains the UML profile mechanism in terms of a full-fledged >MOF2 > > metamodeling capability even though the UML profile mechanism is >explicitly > > defined NOT as such. > > > > There are many ways to do (A) -- using M1 instance specifications is >one of > > many options for representing M0 instances. > >Instance specs specify instances, they are not the same as the instances >they >specify, see next. > > > This approach happens to be conceptually simple and well-suited to the > > problem of addressing (B) such that we can say that the M1 instance > > specifications classified by M1 stereotypes are simply representations >of the > > M0 instances shown in the UML instance specification notation of the >MOF2 > > equivalent illustrations in the spec. > >In particular, instance specs are not instances of the classifiers they >specify >for the instances conforming to them (InstanceSpec::classifiers). They >can't be >values of properties typed by those classifiers. > >Conrad > > UML2.4.1-Figure7.54.png UML2.5-RevAugustDraft-Figs9.31,32,33.png From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: Burkhart Roger M , Sanford Friedenthal , "andrew@omg.org" , Pete Rivett , Nerijus Jankevicius , "Bock, Conrad" , "issues@omg.org" Date: Mon, 27 Aug 2012 16:37:09 -0400 Subject: RE: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Topic: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Index: AQHNhIZnpl6QOY7RgU6czjyEQ0uMopduDNug Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.995418|0.69785|0|white|ugly|871|2|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.69785 p=-0.995418 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-6756-c X-Mailprotector-ID: 0b233bef-d55e-4fe0-9483-c4a81db8e0dd X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q7RKbO2U004413 Nicolas -- I don't agree, and I don't personally think this should even be an issue at this point. This has been discussed and resolved a long time ago -- it is the very reason that instance specifications were called instance "specifications" and not "instances". An instance specification is a value specification so it may be used as the slot for a property in a another instance specification (as in the diagrams you reference) -- but that still makes it a model of a value, not the value itself. This is just the modeling equivalent of the difference between a numeral and a number. -- Ed -----Original Message----- From: "Bock, Conrad" To: "Rouquette, Nicolas F (313K)" , Ed Seidewitz , "issues@omg.org" CC: Burkhart Roger M , Sanford Friedenthal , "andrew@omg.org" , Pete Rivett , Nerijus Jankevicius Date: Tue, 28 Aug 2012 08:19:35 -0400 Subject: RE: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Topic: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Index: AQHNhIZnpl6QOY7RgU6czjyEQ0uMopdvIrHA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Nicolas, > The spec should clearly state that an instance spec is a legitimate > value of a property typed by a classifier. It is, as long as the classifier classifies instance specs. The class Car at M1 does not classify instance specs, so values of properties typed by Car cannot be instance specs (similar examples apply to M2). This is basic to any kind of logical semantics for UML. In particular changing it would mean the typical translations to OWL or first order wouldn't work. The conflation between instance specs and instances is fairly common and one of the purposes of the RTF is to help people distinguish them. Originally instance specs were proposed to be a kind of classifier, and it might be a good idea to consider that again. Then it would be clear that properties typed by classes at M1 do not have instance specs as values at M0. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , Ed Seidewitz , "issues@omg.org" CC: Burkhart Roger M , Sanford Friedenthal , "andrew@omg.org" , Pete Rivett , Nerijus Jankevicius Subject: Re: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Topic: an instance spec should be a legitimate value of a property typed by a classifier. Thread-Index: AQHNhIZnpl6QOY7RgU6czjyEQ0uMopdvIrHAgABAg4A= Date: Tue, 28 Aug 2012 15:59:41 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q7SG0BBn024742 Conrad, See below. On 8/28/12 5:19 AM, "Bock, Conrad" wrote: >Nicolas, > > > The spec should clearly state that an instance spec is a legitimate > > value of a property typed by a classifier. > >It is, as long as the classifier classifies instance specs. Value specifications allow us to use instance specs as values of properties; there are well-formedness constraints of course. The point is that it's perfectly legitimate to use instance specs as values of properties (via value specs). > The class >Car at M1 does not classify instance specs, so values of properties >typed by Car cannot be instance specs (similar examples apply to M2). >This is basic to any kind of logical semantics for UML. In particular >changing it would mean the typical translations to OWL or first order >wouldn't work. > >The conflation between instance specs and instances is fairly common and >one of the purposes of the RTF is to help people distinguish them. I believe you and Ed have been too quick to dismiss this problem under this conflation category. >Originally instance specs were proposed to be a kind of classifier, and >it might be a good idea to consider that again. Then it would be clear >that properties typed by classes at M1 do not have instance specs as >values at M0. This only displaces the problem: how do you tell the difference between M1 instance spec classifiers vs. M1 class classifiers? The problem here is about defining model libraries that, by definition, have a bunch of M1 elements describing M0 instances. There is currently no convention/guideline for doing this -- these M1 elements can be M1 instance specs, M1 classes and possibly other things. The ISO-80000-1-SysML and ISO-80000-1-QUDV model libraries are defined in terms of M1 instance specs. The fundamental problem is that the UML specification does not provide adequate support for defining model libraries. For example, ISO-80000-1-SysML has the following M1 instance specs: Are these M1 instance specs: - different? - the same? - empty? According to the UML spec, all answers are possibly yes. This doesn't help the SysML spec and its users. What the UML spec lacks is the concept of evaluating a model relative to a database of facts taken as true. For example, SysML::Unit and SysML::QuantityKind are 2 stereotypes; I.e., they are M1 classifiers. In theory, their extension could be: - empty - identical - overlapping - disjoint - all of the above. In practice, the only useful interpretation is where their extent is disjoint, possibly empty if the stereotypes have not been applied anywhere. The fact that we encode domain-specific knowledge in UML profiles (e.g., the capability to relate Units, QuantityKinds & ValueTypes) clearly shows that there is definitely a need to support domain-specific interpretation of the UML-based representation of this domain-specific knowledge -- e.g., "Unit", "QuantityKind" as M1 classifiers and domain-specific facts -- e.g., "metre", "length" -- as M1 instance specs that we can relate to their M1 classifiers. In practice, it would be very burdensome and impractical to add a bunch of facts taken as true about the disjointness of M1 classifiers and of M1 instance specs. Instead, I believe most people and tools rely on tacit assumptions of the sort: - if we create M1 instance specs for M1 classifiers defined in a "read-only" model, then M1 classifiers that are not in a generalization relationship are interpreted to be disjoint. The tacit assumption that I dislike the most but is nonetheless pervasive in practice is the following: - M1 instance specs that are distinct elements represent distinct M0 instances I can say that at JPL, we've grown exasperated with the refusals but several UML RTFs to address these important practical modeling problems and this has been a significant factor that led us to look for practical answers elsewhere (e.g., OWL2 and SPARQL). - Nicolas. > >Conrad