Issue 16501: Typed literal definitions should be mapped to their defining datatypes (odm-rtf) Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com) Nature: Revision Severity: Significant Summary: Need to link typed literals to their defining datatypes in the RDF profile and library, not just to the URI for the external xsd definition. Resolution: Resolved to the resolution of 16496 Revised Text: Actions taken: August 19, 2011: received issue April 25, 2014: closed issue Discussion: This issue has been resolved in the resolution for issue 16496, which does include the reference to the rdfs:Datatype, optionally, as a part of the specification for «literal». . End of Annotations:===== m: webmaster@omg.org Date: 19 Aug 2011 13:50:20 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Elisa Kendall Employer: Sandpiper Software mailFrom: ekendall@sandsoft.com Terms_Agreement: I agree Specification: Ontology Definition Metamodel (ODM) Section: 14 FormalNumber: formal/2009-05-01 Version: 1.0 Doc_Year: 2009 Doc_Month: May Doc_Day: 01 Page: 131-180 Title: Typed literal definitions should be mapped to their defining datatypes. Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: X-Katharion-ID: 1377189097.75671.tex1-mh564 (unfiltered-unk) Date: Thu, 22 Aug 2013 09:31:28 -0700 From: Elisa Kendall Organization: Thematix Partners LLC User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "odm-rtf@omg.org" CC: Roy M Bell Subject: Re: Issues 16501 and 16496g (was Re: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd) X-Virus-Scanned: amavisd-new at omg.org Nicolas, On 8/22/2013 8:09 AM, Rouquette, Nicolas F (313K) wrote: From: Pete Adaptive Date: Wednesday, August 21, 2013 10:51 PM To: Nicolas Rouquette , Elisa Kendall , "lvanzandt@nomagic.com" Cc: "odm-rtf@omg.org" , Roy M Subject: RE: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd Some specific responses: Ø 16501That's incorrect because the optional property literal::datatype is typed by "rdfsDatatype", not by "datatype". Not sure I understand your point: are you saying the Literal::datatype property should be typed using UML::Datatype instead of the stereotype rdfsDatatype? BTW Literal::datatype is not optional in the resolution. According to figure 14.2 in 16496g, it is optional. The datatype tag on <> whose type is rdfs:Datatype is optional (i.e., has multiplicity of [0..1] although the assumption, from an implementation perspective, is that (1) this datatype is specified, or (2) the datatypeIRI is specified, or (3) in the absence of either, the datatype is assumed to be xsd:string (an instance of the rdfs:Datatype library element). I'm not sure we said this explicitly, and so we'll need an issue filed against the revision to add this constraint. Between changing letter case (e.g., 14.1.5.3 Datatype vs. "datatype" shown in figure 14.2) and between adding/removing namespace prefixes (e.g., "rdfs:Datatype" and "datatype" or just "Datatype") and between references to metaclasses vs. stereotypes, it is very difficult to read the ODM spec and understand what is being said. I understand, but having context might have helped. You've made some assumptions here that possibly other readers of the spec may make, which is a good point. In this case, my objection comment should have said that the type of the stereotype property Literal::datatype is a stereotype, I.e., Literal::datatype :: rdfsStereotype (I.e., presumably 14.1.6.2 RDFSDatatype in ODM 1.0), rather than the actual UML::Datatype to which the rdfsStereotype (I.e. 14.1.6.2 RDFSDatatype) is applied. In the XMI, do you really expect to see a reference to the instance of the stereotype? Yes, primarily references to library elements that are XML Schema Datatypes, but possibly custom datatypes depending on the ontology. Elisa X-Katharion-ID: 1377194999.46739.tex1-mh570 (unfiltered-unk) Subject: RE: Issues 16501 and 16496g (was Re: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd) Date: Thu, 22 Aug 2013 11:09:57 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 16501 and 16496g (was Re: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd) Thread-Index: Ac6fVUTcbgPJgv3PRKypcLWaPagKJQAA50+w Priority: Urgent From: "Pete Rivett" To: "Elisa Kendall" , Cc: "Roy M Bell" X-Virus-Scanned: amavisd-new at omg.org Ø In the XMI, do you really expect to see a reference to the instance of the stereotype? Ø Yes, primarily references to library elements that are XML Schema Datatypes, but possibly custom datatypes depending on the ontology. Actually this is a subtle but important point and I think Nicolas is right to raise the challenge here. It could have wider ramifications if we have any properties typed by an ODM stereotype. If you draw a Dependency to (a UML Datatype stereotyped «rdfsDatatype») (which is what I think you want to do) then you are actually (in the XMI) linking it to the UML element not the instance of the «rdfsDatatype» stereotype. To link to the latter would actually be very awkward to achieve in UML tools and you would not want to go there. This is the delight of UML Profiling . behind each element on screen you have 2 objects to think of. So the type of the property «literal».datatype should be UML Datatype and there should be a constraint on the «literal» stereotype to say that the target of its datatype property must have the «rdfsDatatype» stereotype (or a subtype) applied. UPDM has actually developed some patterns (using meta-stereotypes) for representing this sort of constraint (and they even generate OCL from the pattern). I don.t think we need to go that far but I think the resolution should be updated. We also need to review other properties on stereotypes where they reference another ODM stereotype instead of the UML class. The big problem for ODM is that, for a given ODM stereotype, you often have a choice of UML class which it extends . which might make this unachievable in some cases (unless you make the type of the property UML Element) and might mean we need to eliminate some choices. Another option is to make use of built-in UML properties instead of introducing new properties on stereotypes. Another problem in this resolution is the «literal».datatypeIRI property which is of type «IRI», defined in resolution to 16495f to extend InstanceSpecification or LiteralString. I think you have 3 choices: - Change the type of «literal».datatypeIRI to String (with constraints). That is consistent with some other resolutions, e.g. in 13938 in this very ballot we have: namespaceIRI: String [1] . the string representing the namespace IRI (This begs the question of whether «IRI» is even needed as a stereotype in its own right. ) - Remove the option to have «IRI» extend LiteralString (which is not practical to use anyway) and change the type of «literal».datatypeIRI to InstanceSpecification, adding constraint that the target must have «IRI» applied - Change the type to the lowest common UML superclass of LiteralString and InstanceSpecification . which is probably PackageableElement. I went through the convenience document we produced for prior Profile resolutions and that did not have any such problems. In one case the type was ambiguous. In the resolution to 12563 the following for owlRestriction (the original ODM 1.0 formal document has the same ambiguity): (8) Under the .Properties. heading, replace . onProperty: Property [1] . identifies the property to which the restriction applies. Is this the ODM stereotype Property or the UML metaclass Property? If the former, it would have the same problem. If the latter then fine but you.d want a constraint that the target UML Property must be stereotyped using the ODM «Property» or a subtype. [I checked the Profile XMI for ODM 1.0 and it turns out to be the latter - UML Property] I see that the examples in that resolution never actually use this onProperty property . they make use of Dependencies stereotyped «onProperty» which is fine. I know it.s a pain with so little time, but I think these are serious enough to reissue the ballot. To help further review do you have a consolidated document or model containing all the profile diagrams or resolutions? It.s a pain to have to open each ballot document one at a time. Pete From: Elisa Kendall [mailto:ekendall@thematix.com] Sent: Thursday, August 22, 2013 9:31 AM To: odm-rtf@omg.org Cc: Roy M Bell Subject: Re: Issues 16501 and 16496g (was Re: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd) Nicolas, On 8/22/2013 8:09 AM, Rouquette, Nicolas F (313K) wrote: From: Pete Adaptive Date: Wednesday, August 21, 2013 10:51 PM To: Nicolas Rouquette , Elisa Kendall , "lvanzandt@nomagic.com" Cc: "odm-rtf@omg.org" , Roy M Subject: RE: [ODM RTF] ***ODM RTF Poll 7 Vote *** Deadline is Friday, August 23rd Some specific responses: Ø 16501That's incorrect because the optional property literal::datatype is typed by "rdfsDatatype", not by "datatype". Not sure I understand your point: are you saying the Literal::datatype property should be typed using UML::Datatype instead of the stereotype rdfsDatatype? BTW Literal::datatype is not optional in the resolution. According to figure 14.2 in 16496g, it is optional. The datatype tag on <> whose type is rdfs:Datatype is optional (i.e., has multiplicity of [0..1] although the assumption, from an implementation perspective, is that (1) this datatype is specified, or (2) the datatypeIRI is specified, or (3) in the absence of either, the datatype is assumed to be xsd:string (an instance of the rdfs:Datatype library element). I'm not sure we said this explicitly, and so we'll need an issue filed against the revision to add this constraint. Between changing letter case (e.g., 14.1.5.3 Datatype vs. "datatype" shown in figure 14.2) and between adding/removing namespace prefixes (e.g., "rdfs:Datatype" and "datatype" or just "Datatype") and between references to metaclasses vs. stereotypes, it is very difficult to read the ODM spec and understand what is being said. I understand, but having context might have helped. You've made some assumptions here that possibly other readers of the spec may make, which is a good point. In this case, my objection comment should have said that the type of the stereotype property Literal::datatype is a stereotype, I.e., Literal::datatype :: rdfsStereotype (I.e., presumably 14.1.6.2 RDFSDatatype in ODM 1.0), rather than the actual UML::Datatype to which the rdfsStereotype (I.e. 14.1.6.2 RDFSDatatype) is applied. In the XMI, do you really expect to see a reference to the instance of the stereotype? Yes, primarily references to library elements that are XML Schema Datatypes, but possibly custom datatypes depending on the ontology. Elisa