<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On a second thought, perhaps it is just better to just get rid of
InformationObject entirely given that making every single class
susceptible of being input/output to a Process an extension of
InformationObject is going to be very messy. We could use a simple
soft-link mechanism, e.g. the facade, to get a similar, less messy
result.<br>
</p>
<p>Flavio</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2021-08-06 3:48 p.m., Flavio Rizzolo
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:dad42b9a-09d1-066e-ecb1-ec98c2fa6225@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true"><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>
</blockquote>
</body>
</html>