<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>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.</p>
<p>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).
<br>
</p>
<p>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. <br>
</p>
<p>Flavio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2021-08-06 7:56 a.m., Hoyle, Larry
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CY4PR0101MB28888BDC735B9D0AC15AC6B3BDF39@CY4PR0101MB2888.prod.exchangelabs.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";
        mso-fareast-language:DE;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        mso-fareast-language:EN-US;}span.EmailStyle23
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0in;}ul
        {margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">As to the last point:<o:p></o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would not remove the identifier from an
abstract classes without thinking about whether all
descendants are intended to be identifiable.<o:p></o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:ddi-srg-bounces@icpsr.umich.edu">ddi-srg-bounces@icpsr.umich.edu</a>
<a class="moz-txt-link-rfc2396E" href="mailto:ddi-srg-bounces@icpsr.umich.edu"><ddi-srg-bounces@icpsr.umich.edu></a>
<b>On Behalf Of </b>Wackerow, Joachim<br>
<b>Sent:</b> Friday, August 6, 2021 6:42 AM<br>
<b>To:</b> DDI Structural Reform Working Group.
<a class="moz-txt-link-rfc2396E" href="mailto:ddi-srg@icpsr.umich.edu"><ddi-srg@icpsr.umich.edu></a><br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI
after model transform<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks Flavio, for the things you noticed.
This is helpful. My comments are below in the message.
<o:p></o:p></p>
<p class="MsoNormal">Keep checking!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Achim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="mso-fareast-language:DE">From:</span></b><span
style="mso-fareast-language:DE"> Flavio Rizzolo <<a
href="mailto:flavio.rizzolo@gmail.com"
moz-do-not-send="true">flavio.rizzolo@gmail.com</a>>
<br>
<b>Sent:</b> Freitag, 6. August 2021 03:39<br>
<b>To:</b> Wackerow, Joachim <<a
href="mailto:Joachim.Wackerow@gesis.org"
moz-do-not-send="true">Joachim.Wackerow@gesis.org</a>>;
DDI Structural Reform Working Group. <<a
href="mailto:ddi-srg@icpsr.umich.edu"
moz-do-not-send="true">ddi-srg@icpsr.umich.edu</a>><br>
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI
after model transform<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p><span lang="DE">A couple of other issues:</span><span
style="mso-fareast-language:DE" lang="DE"><o:p></o:p></span></p>
<p><span lang="DE">- 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.<o:p></o:p></span></p>
<p><b><i>[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.<o:p></o:p></i></b></p>
<p><b><i>I will remove the names in the regular XMI file. I’ll
add the long names to the version with the unique
association names.<o:p></o:p></i></b></p>
<p><b><i>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.<o:p></o:p></i></b></p>
<p>- Identifier appears in all classes in the inheritance
chains. <span lang="DE">
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.<o:p></o:p></span></p>
<p><b><i>[JW] I didn’t think about this.<o:p></o:p></i></b></p>
<p><b><i>I will remove the attribute identifier at all classes
which inherit from a non-abstract class.</i></b><o:p></o:p></p>
<p>- Which brings me to the next issue: abstract classes should
not be identifiable, should they?
<span lang="DE">They are never instantiated, so it seems
pointless they hay an identifier.<o:p></o:p></span></p>
<p><b><i><span lang="DE">[JW] Absolutely.<o:p></o:p></span></i></b></p>
<p><b><i>I’ll remove the attribute identifier from abstract
classes.</i></b><o:p></o:p></p>
<p>Flavio<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span lang="DE">On 2021-08-05 2:00 p.m.,
Flavio Rizzolo wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p><span lang="DE">Achim,<o:p></o:p></span></p>
<p><span lang="DE">A few issues I noticed on a quick review: <o:p></o:p></span></p>
<p><span lang="DE">- 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.<o:p></o:p></span></p>
<p><b><i>[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.<o:p></o:p></i></b></p>
<p><b><i>“Identifier for objects requiring short- or
long-lasting referencing and management.” seems to be
good enough.<o:p></o:p></i></b></p>
<p><b><i>The suggested removal is fine with me.<o:p></o:p></i></b></p>
<p>- Some of the attributes, e.g. ddiIdentifier, uri, appear
to be of type "EA_Java_Types_Package".
<span lang="DE">I'm not sure how that happened. <o:p></o:p></span></p>
<p><b><i>[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.</i></b><o:p></o:p></p>
<p>- There is a ModelIdentification datatype, right under the
DataTypes package, that doesn't seem to be used anywhere.
<o:p></o:p></p>
<p><b><i>[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.<o:p></o:p></i></b></p>
<p><b><i>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></b><o:p></o:p></p>
<p>- I was just going over the Documentation.xlsx and noticed
a couple of enumerations that didn't ring a bell.
<span lang="DE">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.<o:p></o:p></span></p>
<p><b><i>[JW] StringStructureType was removed because I
simplified all string data types. It is now an external
controlled vocabulary. Hard coding would be too limited.<o:p></o:p></i></b></p>
<p><b><i>WorkflowPattern is not used at all. I removed it but
missed to document it.<o:p></o:p></i></b></p>
<p>That's all for now. <span lang="DE">I'll keep checking.<o:p></o:p></span></p>
<p><span lang="DE">Flavio<o:p></o:p></span></p>
<p><span lang="DE"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="DE">On 2021-07-30 2:59
p.m., Wackerow, Joachim wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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.<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">I documented all changes in <a
href="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"
moz-do-not-send="true">
ModelTransformation_2021-07-30.docx</a>.<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">The file lists also some items which
need documentation. Volunteers sought.<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">While doing this work I filed a couple
of additional issues:<span lang="DE"><o:p></o:p></span></p>
<ol style="margin-top:0in" type="1" start="1">
<li class="MsoListParagraph"
style="color:blue;margin-left:0in;mso-list:l0 level1
lfo3">
<span class="MsoHyperlink"><a
href="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"
moz-do-not-send="true"><span lang="DE">Missing
documentation <b>CDI-57</b></span></a></span><span
lang="DE"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="color:blue;margin-left:0in;mso-list:l0 level1
lfo3">
<span class="MsoHyperlink"><a
href="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"
moz-do-not-send="true">Boolean class attributes:
should they have a default value? <b>CDI-56</b></a></span><span
lang="DE"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="color:blue;margin-left:0in;mso-list:l0 level1
lfo3">
<span class="MsoHyperlink"><a
href="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"
moz-do-not-send="true">Data type ObjectName
attributes are not clear. <b><span lang="DE">CDI-55</span></b></a></span><span
style="color:windowtext;mso-fareast-language:DE">
</span><span lang="DE"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="color:blue;margin-left:0in;mso-list:l0 level1
lfo3">
<span class="MsoHyperlink"><a
href="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"
moz-do-not-send="true">Data type name
"SpecificationType" too generic <b>CDI-54</b></a></span><span
lang="DE"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo3"><span
class="MsoHyperlink"><a
href="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"
moz-do-not-send="true">Review names of enumerations
and data types. Several have the suffix 'type'. <b><span
lang="DE">CDI-58</span></b></a></span><span
lang="DE"><o:p></o:p></span></li>
</ol>
<p class="MsoNormal"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">The new files include everything below
DDICDIModels. The abstraction stereotypes like trace are
maintained. Diagrams get lost in this process.<span
lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">The new XMI files (<a
href="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"
moz-do-not-send="true">DDI-CDI_2021-07-30.xmi</a>,
<a
href="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"
moz-do-not-send="true">
DDI-CDI_UniqueAssociationNames_2021-07-30.xmi</a>) are
available for download.<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">Please review. There might be issues.<span
lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal">Achim<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="mso-fareast-language:DE" lang="DE"><o:p> </o:p></span></p>
<pre><span lang="DE">_______________________________________________<o:p></o:p></span></pre>
<pre><span lang="DE">DDI-SRG mailing list<o:p></o:p></span></pre>
<pre><span lang="DE"><a href="mailto:DDI-SRG@icpsr.umich.edu" moz-do-not-send="true">DDI-SRG@icpsr.umich.edu</a><o:p></o:p></span></pre>
<pre><span lang="DE"><a href="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" moz-do-not-send="true">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a><o:p></o:p></span></pre>
</blockquote>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
DDI-SRG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a>
</pre>
</blockquote>
</body>
</html>