<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>This user/implementation guide is becoming more critical the more
we review the model. How, and when, to use identifiable is the
latest addition to the guide, I'd say. <br>
</p>
<p>As part of the Process model review, I have a couple of proposals
related to InformationObject:</p>
<p>- Current definition: "An InformationObject may be a data object
or a metadata object either used or produced by an Activity. A
program that creates InformationObjects is also an
InformationObject."</p>
<p>- Proposed definition: "Data or Conceptual object playing the
role of input or output of an Activity." I don't think we want to
have programs as input/outputs at this point, that would be too
"meta" and create some confusion. <br>
</p>
<p>- Currently, InformationObject is only the parent class of
different types of Datasets, VariableCollection and
EnumerationDomain. No individual values, variables or even
concepts of any kind. By restricting InformationObjecs to those
classes, the usability of the model in practical scenarios is
vastly reduced. I suggest to either make every class in Conceptual
and DataDescription a subtype of InformationEntity, or at the very
least add to the existing ones Concept and Datum. <br>
</p>
<p>- Finally, rename it to "Entity", or "InformationEntity", or
something similar, more inline with PROV and others. I don't like
the use of "object" when actually referring to a class in GSIM,
and I think we could just avoid using it here.</p>
<p>Flavio</p>
<br>
<div class="moz-cite-prefix">On 2021-08-06 2:39 p.m., A. G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1181929075.399152.1628275156557@mail.yahoo.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="ydpa393233fyahoo-style-wrap"
style="font-family:Helvetica Neue, Helvetica, Arial,
sans-serif;font-size:13px;">
<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 <a class="moz-txt-link-rfc2396E" href="mailto:flavio.rizzolo@gmail.com"><flavio.rizzolo@gmail.com></a> 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"
moz-do-not-send="true">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"
moz-do-not-send="true"><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"
moz-do-not-send="true">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"
moz-do-not-send="true">
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"
moz-do-not-send="true">
<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"
moz-do-not-send="true">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">
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"
moz-do-not-send="true"><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"
moz-do-not-send="true">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"
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;"> </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"
moz-do-not-send="true">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"
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></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"
moz-do-not-send="true">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"
moz-do-not-send="true">
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 style=""
lang="DE"> </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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">DDI-SRG@icpsr.umich.edu</a><br
clear="none">
<a shape="rect"
href="http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg"
target="_blank" moz-do-not-send="true">http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg</a><br
clear="none">
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>