<html><head></head><body><div class="ydpa393233fyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div dir="ltr" data-setdir="false">Flavio:</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">It has become clear to me as I have looked at a couple of examples that what you say is true.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">One major topic for the Dagstuhl week will be to design and document a methodology for creating implementation guides. These would describe both the selection of classes to be used from the model, and relevant choices about syntac representation.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Without this - functioning basically as a checklist for a community implementing the model, but one which can be shared with others to support interoperability - I do not see a model of this complexity being practically useful.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">One aspect of this which has become evident is that with a minimum received metadata payload, it is possible to use the model to derive much greater richness within the system processing that metadata, especially if the implementation details are known.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">The best example of this I have seen so far is an RDF implementation prototype where users are expected to describe their instance variables, and to indicate whether the concept employed and/or the enumerated values are taken from an authoritative source. With this information it is possible to populate the entire variable cascade in a useful way, suitable for a system designed to identify reuse programmatically.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I think this kind of hidden complexity is actually very powerful. Although we need responsible users it will help a lot if we can tell them what we mean by "responsible". That burden should be as light as possible for our adopters.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Cheers,</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Arofan</div><div><br></div>
</div><div id="yahoo_quoted_8527513636" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, August 6, 2021, 06:09:04 PM GMT+2, Flavio Rizzolo <flavio.rizzolo@gmail.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="yiv0598211313"><div>
<p>That would depend on the syntax representation, in XML or JSON
you can use the nesting of elements without needing further
references... In any case, I lost track of how many times we went
back and forth on this, I made the suggestion because I thought we
were not identifying everything in this iteration... my bad.<br clear="none">
</p>
<p>The identifier is optional anyways, we could emphasize in the
documentation that if the syntax representation of your choice
doesn't need it in certain cases, then don't use it. That would
create other interoperability problems since some people might
drop identifiers even when they are really required, but I don't
see any way around that since we are given tons of flexibility to
the users, and with great flexibility comes great
responsibility... <br clear="none">
</p>
<p>Flavio</p>
<br clear="none">
<div class="yiv0598211313yqt5352420460" id="yiv0598211313yqt91024"><div class="yiv0598211313moz-cite-prefix">On 2021-08-06 10:57 a.m., Hoyle, Larry
wrote:<br clear="none">
</div>
<blockquote type="cite">
</blockquote></div></div><div class="yiv0598211313yqt5352420460" id="yiv0598211313yqt66826"><style> _filtered {} _filtered {} _filtered {}#yiv0598211313 p.yiv0598211313MsoNormal, #yiv0598211313 li.yiv0598211313MsoNormal, #yiv0598211313 div.yiv0598211313MsoNormal
{margin:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv0598211313 a:link, #yiv0598211313 span.yiv0598211313MsoHyperlink
{color:blue;text-decoration:underline;}#yiv0598211313 pre
{margin:0in;font-size:10.0pt;font-family:"Courier New";}#yiv0598211313 p.yiv0598211313MsoListParagraph, #yiv0598211313 li.yiv0598211313MsoListParagraph, #yiv0598211313 div.yiv0598211313MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv0598211313 span.yiv0598211313HTMLPreformattedChar
{font-family:Consolas;}#yiv0598211313 span.yiv0598211313EmailStyle23
{font-family:"Calibri", sans-serif;color:windowtext;}#yiv0598211313 .yiv0598211313MsoChpDefault
{font-size:10.0pt;}#yiv0598211313 div.yiv0598211313WordSection1
{}#yiv0598211313 ol
{margin-bottom:0in;}#yiv0598211313 ul
{margin-bottom:0in;}</style><div><div class="yiv0598211313WordSection1">
<p class="yiv0598211313MsoNormal">Unfortunately, anything that is at the
navigable end of an association needs an identifier. This does
not mean that these need to be heavily (centrally) managed – a
random UUID could work for the ddiIdentifier attribute of the
Identifier. The Position class is an example. A list needs to
be able to refer to the positions of the objects in the list.
If these Positions do not have unique identifiers, a saved
instance of the list and its associated positions becomes
unusable.</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">Since we cannot foresee future uses of
existing classes in the model, all classes should have an
identifier property. This is how we have been doing this for
quite a while now. This is one of the primary distinctions
between classes and structured datatypes.</p>
<p class="yiv0598211313MsoNormal">Please let’s not get into remodeling this
at this late date.</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">Larry</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal"> </p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in;">
<p class="yiv0598211313MsoNormal"><b>From:</b>
<a rel="nofollow noopener noreferrer" shape="rect" class="yiv0598211313moz-txt-link-abbreviated" ymailto="mailto:ddi-srg-bounces@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg-bounces@icpsr.umich.edu">ddi-srg-bounces@icpsr.umich.edu</a>
<a rel="nofollow noopener noreferrer" shape="rect" class="yiv0598211313moz-txt-link-rfc2396E" ymailto="mailto:ddi-srg-bounces@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg-bounces@icpsr.umich.edu"><ddi-srg-bounces@icpsr.umich.edu></a>
<b>On Behalf Of </b>Flavio Rizzolo<br clear="none">
<b>Sent:</b> Friday, August 6, 2021 8:40 AM<br clear="none">
<b>To:</b> <a rel="nofollow noopener noreferrer" shape="rect" class="yiv0598211313moz-txt-link-abbreviated" ymailto="mailto:ddi-srg@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg@icpsr.umich.edu">ddi-srg@icpsr.umich.edu</a><br clear="none">
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI
after model transform</p>
</div>
</div>
<p class="yiv0598211313MsoNormal"> </p>
<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). </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. </p>
<p>Flavio</p>
<p> </p>
<div>
<p class="yiv0598211313MsoNormal">On 2021-08-06 7:56 a.m., Hoyle, Larry
wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;">
<p class="yiv0598211313MsoNormal">As to the last point:</p>
<p class="yiv0598211313MsoNormal">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.
</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">I would not remove the identifier from an
abstract classes without thinking about whether all
descendants are intended to be identifiable.</p>
<p class="yiv0598211313MsoNormal"> </p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in;">
<p class="yiv0598211313MsoNormal"><b>From:</b> <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:ddi-srg-bounces@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg-bounces@icpsr.umich.edu">
ddi-srg-bounces@icpsr.umich.edu</a> <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:ddi-srg-bounces@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg-bounces@icpsr.umich.edu">
<ddi-srg-bounces@icpsr.umich.edu></a> <b>On
Behalf Of </b>Wackerow, Joachim<br clear="none">
<b>Sent:</b> Friday, August 6, 2021 6:42 AM<br clear="none">
<b>To:</b> DDI Structural Reform Working Group. <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:ddi-srg@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg@icpsr.umich.edu">
<ddi-srg@icpsr.umich.edu></a><br clear="none">
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI
after model transform</p>
</div>
</div>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">Thanks Flavio, for the things you
noticed. This is helpful. My comments are below in the
message.
</p>
<p class="yiv0598211313MsoNormal">Keep checking!</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">Achim</p>
<p class="yiv0598211313MsoNormal"> </p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in;">
<p class="yiv0598211313MsoNormal"><b><span style="">From:</span></b><span style=""> Flavio Rizzolo <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:flavio.rizzolo@gmail.com" target="_blank" href="mailto:flavio.rizzolo@gmail.com">flavio.rizzolo@gmail.com</a>>
<br clear="none">
<b>Sent:</b> Freitag, 6. August 2021 03:39<br clear="none">
<b>To:</b> Wackerow, Joachim <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:Joachim.Wackerow@gesis.org" target="_blank" href="mailto:Joachim.Wackerow@gesis.org">Joachim.Wackerow@gesis.org</a>>;
DDI Structural Reform Working Group. <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:ddi-srg@icpsr.umich.edu" target="_blank" href="mailto:ddi-srg@icpsr.umich.edu">ddi-srg@icpsr.umich.edu</a>><br clear="none">
<b>Subject:</b> Re: [DDI-SRG] [CDI] new Canonical XMI
after model transform</span></p>
</div>
</div>
<p class="yiv0598211313MsoNormal"><span lang="DE"> </span></p>
<p><span lang="DE">A couple of other issues:</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.</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.</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.</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.</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.</span></p>
<p><b><i>[JW] I didn’t think about this.</i></b></p>
<p><b><i>I will remove the attribute identifier at all classes
which inherit from a non-abstract class.</i></b></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.</span></p>
<p><b><i><span lang="DE">[JW] Absolutely.</span></i></b></p>
<p><b><i>I’ll remove the attribute identifier from abstract
classes.</i></b></p>
<p>Flavio</p>
<p class="yiv0598211313MsoNormal"> </p>
<div>
<p class="yiv0598211313MsoNormal"><span lang="DE">On 2021-08-05 2:00
p.m., Flavio Rizzolo wrote:</span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;">
<p><span lang="DE">Achim,</span></p>
<p><span lang="DE">A few issues I noticed on a quick review:
</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.</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.</i></b></p>
<p><b><i>“Identifier for objects requiring short- or
long-lasting referencing and management.” seems to be
good enough.</i></b></p>
<p><b><i>The suggested removal is fine with me.</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. </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></p>
<p>- There is a ModelIdentification datatype, right under
the DataTypes package, that doesn't seem to be used
anywhere.
</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.</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></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.</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.</i></b></p>
<p><b><i>WorkflowPattern is not used at all. I removed it
but missed to document it.</i></b></p>
<p>That's all for now. <span lang="DE">I'll keep checking.</span></p>
<p><span lang="DE">Flavio</span></p>
<p><span lang="DE"> </span></p>
<div>
<p class="yiv0598211313MsoNormal"><span lang="DE">On 2021-07-30 2:59
p.m., Wackerow, Joachim wrote:</span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;">
<p class="yiv0598211313MsoNormal">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.</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">I documented all changes in <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" 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%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223322476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fcJpNbWGyBHeqSODTIwCgVHjq%2F9gxon7%2F8lB7pagvBE%3D&reserved=0">
ModelTransformation_2021-07-30.docx</a>.</p>
<p class="yiv0598211313MsoNormal">The file lists also some items which
need documentation. Volunteers sought.</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">While doing this work I filed a
couple of additional issues:</p>
<ol style="margin-top:0in;" type="1" start="1"><li class="yiv0598211313MsoListParagraph" style="color:blue;margin-left:0in;">
<span class="yiv0598211313MsoHyperlink"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-57&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223332464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=faHh4c%2Fj%2FpM5bQFlonDnJjWeiSGNx4BUurxb88vzKAs%3D&reserved=0"><span lang="DE">Missing
documentation <b>CDI-57</b></span></a></span></li><li class="yiv0598211313MsoListParagraph" style="color:blue;margin-left:0in;">
<span class="yiv0598211313MsoHyperlink"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-56&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223332464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZSjwVi%2BsDyC5HMdMHfDPhzmYpWK6EBbb5Wg7Cc54eFI%3D&reserved=0">Boolean class attributes:
should they have a default value? <b>CDI-56</b></a></span></li><li class="yiv0598211313MsoListParagraph" style="color:blue;margin-left:0in;">
<span class="yiv0598211313MsoHyperlink"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-55&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223342460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XYiTITReBO%2BMSZJD%2FspKTP%2FExt%2F3ew%2BBow9tLMUOV84%3D&reserved=0">Data type ObjectName
attributes are not clear. <b><span lang="DE">CDI-55</span></b></a></span><span style="color:windowtext;">
</span></li><li class="yiv0598211313MsoListParagraph" style="color:blue;margin-left:0in;">
<span class="yiv0598211313MsoHyperlink"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-54&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223342460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LHIeTvUxcWyv6Q9wqXlST3UiYUJzYWyUOvF3rGThc0M%3D&reserved=0">Data type name
"SpecificationType" too generic <b>CDI-54</b></a></span></li><li class="yiv0598211313MsoListParagraph" style="margin-left:0in;"><span class="yiv0598211313MsoHyperlink"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-58&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223352454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HiNxBmzdMDp9GI93%2FqMON6HJklaqgT9uEgv86lcuXvE%3D&reserved=0">Review names of
enumerations and data types. Several have the
suffix 'type'. <b><span lang="DE">CDI-58</span></b></a></span></li></ol>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">The new files include everything
below DDICDIModels. The abstraction stereotypes like
trace are maintained. Diagrams get lost in this process.</p>
<p class="yiv0598211313MsoNormal">The new XMI files (<a rel="nofollow noopener noreferrer" shape="rect" target="_blank" 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%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223352454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=leUhBgg258UiamqdktvsK15NTstsvv0gLaVAS%2BPg6eY%3D&reserved=0">DDI-CDI_2021-07-30.xmi</a>,
<a rel="nofollow noopener noreferrer" shape="rect" target="_blank" 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%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223362451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nUIHHZaIxk5f46RCQbjOJ5wI6hRnhFvWqx8zpFJiaSg%3D&reserved=0">
DDI-CDI_UniqueAssociationNames_2021-07-30.xmi</a>) are
available for download.</p>
<p class="yiv0598211313MsoNormal">Please review. There might be issues.</p>
<p class="yiv0598211313MsoNormal"> </p>
<p class="yiv0598211313MsoNormal">Achim</p>
<p class="yiv0598211313MsoNormal" style="margin-bottom:12.0pt;"><span lang="DE" style=""> </span></p>
<pre><span lang="DE">_______________________________________________</span></pre>
<pre><span lang="DE">DDI-SRG mailing list</span></pre>
<pre><span lang="DE"><a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:DDI-SRG@icpsr.umich.edu" target="_blank" href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a></span></pre>
<pre><span lang="DE"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" 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%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223372444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CHEvcw%2BTHHfyBNDnOsWB%2BOe%2FQTi9fqQclyJ%2FB4oUXE8%3D&reserved=0">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a></span></pre>
</blockquote>
</blockquote>
<p class="yiv0598211313MsoNormal"><br clear="none">
<br clear="none">
</p>
<pre>_______________________________________________</pre>
<pre>DDI-SRG mailing list</pre>
<pre><a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:DDI-SRG@icpsr.umich.edu" target="_blank" href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a></pre>
<pre><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" 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%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223372444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CHEvcw%2BTHHfyBNDnOsWB%2BOe%2FQTi9fqQclyJ%2FB4oUXE8%3D&reserved=0">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a></pre>
</blockquote>
</div>
</div></div></div><div class="yqt5352420460" id="yqt57365">_______________________________________________<br clear="none">DDI-SRG mailing list<br clear="none"><a shape="rect" ymailto="mailto:DDI-SRG@icpsr.umich.edu" href="mailto:DDI-SRG@icpsr.umich.edu">DDI-SRG@icpsr.umich.edu</a><br clear="none"><a shape="rect" href="http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg" target="_blank">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a><br clear="none"></div></div>
</div>
</div></body></html>