[DDI-SRG] [CDI] new Canonical XMI after model transform

Fri Aug 6 09:40:17 EDT 2021

Yes, that's a good point Larry. The question is whether that is the 
case, or it's just safer to remove them from all abstract classes with 
the idea we'll add them in the concrete classes as necessary.

The pattern classes also have identifier, even in the cases in which the 
concrete classes shouldn't have them, e.g. keys and keymembers. I think 
the criteria for having identifiers is not only that they will be 
instantiated but also that the instance can live on its own and is worth 
referencing, which is not the case of something like keys and keymembers 
(besides, it would really be an overkill to add identifier, which is not 
light, to something like a keymember, which is essentially a pointer 
linking data points).

The idea at some point was to use composition to indicate when two 
classes formed a single whole so that the parts didn't require separate 
identification from the whole. They keys certainly satisfy that, since 
the are parts of a dataset. Position in List is another example.

Flavio

On 2021-08-06 7:56 a.m., Hoyle, Larry wrote:
>
> As to the last point:
>
> I would think that adding an identifier to an abstract class is done 
> not because I would think that adding an identifier to an abstract 
> class is done not because you expect to identify the abstract class 
> itself, but because you intend that all classes inheriting from it are 
> identifiable. A Flavio pointed out, by being abstract, a class is 
> never intended to be used directly. It only exists to describe what 
> properties and relationships its descendants must have.
>
> I would not remove the identifier from an abstract classes without 
> thinking about whether all descendants are intended to be identifiable.
>
> *From:* ddi-srg-bounces at icpsr.umich.edu 
> <ddi-srg-bounces at icpsr.umich.edu> *On Behalf Of *Wackerow, Joachim
> *Sent:* Friday, August 6, 2021 6:42 AM
> *To:* DDI Structural Reform Working Group. <ddi-srg at icpsr.umich.edu>
> *Subject:* Re: [DDI-SRG] [CDI] new Canonical XMI after model transform
>
> Thanks Flavio, for the things you noticed. This is helpful. My 
> comments are below in the message.
>
> Keep checking!
>
> Achim
>
> *From:*Flavio Rizzolo <flavio.rizzolo at gmail.com 
> <mailto:flavio.rizzolo at gmail.com>>
> *Sent:* Freitag, 6. August 2021 03:39
> *To:* Wackerow, Joachim <Joachim.Wackerow at gesis.org 
> <mailto:Joachim.Wackerow at gesis.org>>; DDI Structural Reform Working 
> Group. <ddi-srg at icpsr.umich.edu <mailto:ddi-srg at icpsr.umich.edu>>
> *Subject:* Re: [DDI-SRG] [CDI] new Canonical XMI after model transform
>
> A couple of other issues:
>
> - The "refine" association seems to have a unique name now, even in 
> the non-unique names xmi. For instance, Concept "refines" 
> IndividualMember. Instead, we have Concept 
> "Concept_refines_IndividualMember" IndividualMember.
>
> */[JW] The name should be probably removed in the regular XMI file. 
> The long name should be in the version with the unique association 
> names. The background of the refine names is that some UML tools are 
> not able to consume the abstraction stereotypes. They just ignore them 
> which results in a Abstraction relationship without further 
> specification. Using the name is a workaround. But this is confusing 
> in a tool like EA which can consume the abstraction stereotypes. The 
> name repeats what is already expressed in the specific abstraction 
> relationship. Another workaround would be to describe the kind of 
> relationship in the definition./*
>
> */I will remove the names in the regular XMI file. I’ll add the long 
> names to the version with the unique association names./*
>
> */You could think about if the abstraction definitions could be 
> improved in a way that the kind of relationship is clear even if an 
> UML tool doesn’t understand the related stereotypes like refine./*
>
> - Identifier appears in all classes in the inheritance chains. For 
> instance, Activity has Identifier, and so does Step, which is an 
> extension of Activity. However, only the top non-abstract class in any 
> inheritance chain should have Identifiable.
>
> */[JW] I didn’t think about this./*
>
> */I will remove the attribute identifier at all classes which inherit 
> from a non-abstract class./*
>
> - Which brings me to the next issue: abstract classes should not be 
> identifiable, should they? They are never instantiated, so it seems 
> pointless they hay an identifier.
>
> */[JW] Absolutely./*
>
> */I’ll remove the attribute identifier from abstract classes./*
>
> Flavio
>
> On 2021-08-05 2:00 p.m., Flavio Rizzolo wrote:
>
>     Achim,
>
>     A few issues I noticed on a quick review:
>
>     - The definition of Identifier seems old. It says "Basic object
>     requiring identification. Elements of this type are versioned and
>     provide administrative metadata properties." It's a datatype now,
>     so it should probably say "identifier for objects requiring short-
>     or long-lasting referencing and management", or something like
>     that. The example seems wrong as well "Use for First Order Classes
>     whose content does not need to be discoverable in its own right
>     but needs to be related to multiple classes.". I suggest to remove it.
>
>     */[JW] For the next transformation run, I would need the
>     documentation of both the class attribute identifier and the data
>     type Identifier. It could be the same definition./*
>
>     */“Identifier for objects requiring short- or long-lasting
>     referencing and management.” seems to be good enough./*
>
>     */The suggested removal is fine with me./*
>
>     - Some of the attributes, e.g. ddiIdentifier, uri, appear to be of
>     type "EA_Java_Types_Package". I'm not sure how that happened.
>
>     */[JW] I typed them as strings. I will look into this. This is an
>     issue with EA and their use of UML primitives and how they express
>     them in their version of XMI./*
>
>     - There is a ModelIdentification datatype, right under the
>     DataTypes package, that doesn't seem to be used anywhere.
>
>     */[JW] I added this already to the public review version. It is
>     not used anywhere in the model but it can be used by any program
>     which uses the model or its representations. This way a program
>     can recognize with which specification and version it deals with./*
>
>     */This could stay on the level of the data types like currently or
>     it could be located just below DDICDILibrary. What do you think?/*
>
>     - I was just going over the Documentation.xlsx and noticed a
>     couple of enumerations that didn't ring a bell. I checked and
>     couldn't find them in the latest EA file. They are WorkflowPattern
>     and StringStructureType. There might be others. I'm not sure where
>     they are coming from.
>
>     */[JW] StringStructureType was removed because I simplified all
>     string data types. It is now an external controlled vocabulary.
>     Hard coding would be too limited./*
>
>     */WorkflowPattern is not used at all. I removed it but missed to
>     document it./*
>
>     That's all for now. I'll keep checking.
>
>     Flavio
>
>     On 2021-07-30 2:59 p.m., Wackerow, Joachim wrote:
>
>         I did the programmatic model transformation for a couple of
>         issues we talked about. Prior to that I edited manually the EA
>         model regarding some other issues.
>
>         I documented all changes in
>         ModelTransformation_2021-07-30.docx
>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2F8fkxs38snd6ss2d%2FModelTransformation_2021-07-30.docx%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421562496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yy7JfYuXxxZ2B0jfLJCYRMSW3AckGg4dsGzOJ5BhVKM%3D&reserved=0>.
>
>         The file lists also some items which need documentation.
>         Volunteers sought.
>
>         While doing this work I filed a couple of additional issues:
>
>          1. Missing documentation *CDI-57*
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-57&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421572488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wzokB8P3RGqh%2BtoR4qone4vJjK2NYpKDZSapB%2BdJ2aI%3D&reserved=0>
>          2. Boolean class attributes: should they have a default
>             value? *CDI-56*
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-56&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421582482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xVW%2FuSHt%2BbGQT%2FSwpRoLrtzryxSakq1ImxmbNefm9TA%3D&reserved=0>
>          3. Data type ObjectName attributes are not clear. *CDI-55*
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-55&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421582482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bFWWYRhntJjNnMWw9UkYzqRH4toedsr7MIHAtnioSWw%3D&reserved=0>
>          4. Data type name "SpecificationType" too generic *CDI-54*
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-54&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421592481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SU%2FylrpOKJ9QvzFKtsitt4Czsg0JuS%2B3ENtN9q2T0ew%3D&reserved=0>
>          5. Review names of enumerations and data types. Several have
>             the suffix 'type'. *CDI-58*
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-58&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421592481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qnhvqRCaDTCpNUPp6Wa3E73mX2qIYbLzYgg%2FAURjsXk%3D&reserved=0>
>
>         The new files include everything below DDICDIModels. The
>         abstraction stereotypes like trace are maintained. Diagrams
>         get lost in this process.
>
>         The new XMI files (DDI-CDI_2021-07-30.xmi
>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Foizidnadhqeo1s7%2FDDI-CDI_2021-07-30.xmi%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421602472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F%2FipwqSRVkrN7sETk1IHsIJZjlmFbBQ0FdkgRM7%2F3sI%3D&reserved=0>,
>         DDI-CDI_UniqueAssociationNames_2021-07-30.xmi
>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fsv3h4cof4i499xx%2FDDI-CDI_UniqueAssociationNames_2021-07-30.xmi%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421602472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5kkQ43Su%2FfksNaQssbt3ogsD8C5rfFLHTc4ho2%2Bx%2FiY%3D&reserved=0>)
>         are available for download.
>
>         Please review. There might be issues.
>
>         Achim
>
>         _______________________________________________
>
>         DDI-SRG mailing list
>
>         DDI-SRG at icpsr.umich.edu <mailto:DDI-SRG at icpsr.umich.edu>
>
>         http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg
>         <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.icpsr.umich.edu%2Fmailman%2Flistinfo%2Fddi-srg&data=04%7C01%7Clarryhoyle%40ku.edu%7C00e84f0f33674dba073a08d958cf3b9c%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638470421612467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=axYuMkIULa5ixJl1LwwgrJm8UZmwtdUribHIxljZoyQ%3D&reserved=0>
>
>
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.icpsr.umich.edu/pipermail/ddi-srg/attachments/20210806/6e797609/attachment-0001.html 