<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Unfortunately, I won't be able to make it tomorrow. I'll write my
proposal here as a reference.</p>
<p>I think our only priority now should be to make the XSD work and
get the spec in place. The best way to do that is to have a
separation of PIM and PSM. For now, it could be just a separate
copy, not ideal but practical. That means we make changes to the
PIM when the change is conceptual, i.e. platform independent, and
we make changes to the PSM whenever it's purely about the XSD,
i.e. platform specific. Linking the Process Model and the Data
Description is conceptual, so it goes into the PIM. Adding ids to
classes that should not be referenced directly, i.e. the plumbing,
as Larry said, should be done in the PSM because it's only needed
in some syntax representations. The reason for having these two
models is the same as always: separation of concerns. I understand
the tight timeline, so that's why we'll do it by hand rather than
by a proper set of automated rules. The alternative, pilling
everything up in a single model, impacts documentation, diagrams,
and other implementations in the future. Besides, it doesn't even
save us time now. <br>
</p>
<p>It seems to me the only real problem at hand is that the XSD
needs some ids that are not in the PIM. Hence, we add ids as
necessary in the PSM to get a working XSD. Just a single id
attribute. Easy. If in the process we find something conceptual to
fix in the PIM, e.g. a missing association, we fix it there as
well. Easy again.</p>
<p>Now, keeping in mind the tight timeline, the issue about
identification and annotations we discussed is not actually
breaking the XSD, so it shouldn't be a priority. If it can be
done, great. If not, we flag it and do it after the review. <br>
</p>
<p>In any case, whether we do it one way or the other, for sure we
shouldn't add identification to the plumbing in the PIM. Some
classes do not have identification by design. It's not a bug.
Adding ids and a whole bunch of identification content to classes
in the PIM that don't need it, e.g. Position in a List, or
InstanceValue, would be overkill, unnecessary, and wrong. <br>
</p>
<p>In fact, it would be like changing the directions of associations
in the PIM just because the XSD needs them. I refer the reader to
this Jira issue related to this topic:</p>
<p><a class="moz-txt-link-freetext" href="https://ddi-alliance.atlassian.net/browse/DMT-319">https://ddi-alliance.atlassian.net/browse/DMT-319</a></p>
<p><i><u>Hence my proposal</u>: add a simple id attribute, say a
String, to the PSM classes that don't have ids to get a working
XSD. Then, change the overall identification approach when
everything else is working, time permitting. </i><br>
</p>
<p>That way, we can have the necessary time to get a Process model
working and other parts of the PIM that might need fixing. </p>
<p>Flavio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 05/02/2020 11:27 a.m., Hilde Orten
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3cd1ec110f894a289cbea481f8d15dbc@nsd.no">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:453209223;
mso-list-type:hybrid;
mso-list-template-ids:569017532 68419599 68419609 68419611 68419599 68419609 68419611 68419599 68419609 68419611;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1305505016;
mso-list-type:hybrid;
mso-list-template-ids:355393894 68419599 68419609 68419611 68419599 68419609 68419611 68419599 68419609 68419611;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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"><span
style="color:#1F497D;mso-fareast-language:EN-US">Achim,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">To my understanding point 1. to 3. were not
discussed, and no firm agreement on 4. and 5.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Point 1. seems to be agreed in the emails?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Talk to you tomorrow!<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Best wishes,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US">Hilde<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> <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> onsdag 5. februar 2020 17:14<br>
<b>To:</b> DDI - Structural Reform 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] [MRT] Open model issues
for decision<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Was
there agreement on any of the open issues in the list below?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">If
yes, I could continue to work on this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Achim<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif"
lang="EN-US"> Hoyle, Larry [<a
href="mailto:larryhoyle@ku.edu" moz-do-not-send="true">mailto:larryhoyle@ku.edu</a>]
<br>
<b>Sent:</b> Wednesday, February 5, 2020 16:22<br>
<b>To:</b> Wackerow, Joachim; DDI - Structural Reform
Group<br>
<b>Subject:</b> RE: [MRT] Open model issues for decision<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Classes
like Individual inherit from an identifiable super class so
they are also identifiable.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Basically
there are two kinds of classes. Those that might be
referenced and those that are just plumbing and don’t need
to be referenced. The latter includes things like position
pointers. These are classes because they reference other
classes, but one would never reuse them.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> <a
href="mailto:ddi-srg-bounces@icpsr.umich.edu"
moz-do-not-send="true">
ddi-srg-bounces@icpsr.umich.edu</a> <<a
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>
<b>Sent:</b> Wednesday, February 5, 2020 8:34 AM<br>
<b>To:</b> DDI - Structural Reform 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] [MRT] Open model issues
for decision<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Here
is an additional list. Attached is a list of all classes and
their possible super classes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">The
identifiable ones are marked in blue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">The
classes without a super class are marked in red.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Achim<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif"
lang="EN-US">
<a href="mailto:ddi-srg-bounces@icpsr.umich.edu"
moz-do-not-send="true">ddi-srg-bounces@icpsr.umich.edu</a>
[<a href="mailto:ddi-srg-bounces@icpsr.umich.edu"
moz-do-not-send="true">mailto:ddi-srg-bounces@icpsr.umich.edu</a>]
<b>On Behalf Of </b>Wackerow, Joachim<br>
<b>Sent:</b> Wednesday, February 5, 2020 13:35<br>
<b>To:</b> DDI - Structural Reform Group<br>
<b>Subject:</b> [DDI-SRG] [MRT] Open model issues for
decision<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Here is a list of open
model issues.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The goal would be that
we either find today an agreement or we describe the issue
and possible solutions and park the issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I’ll then make changes
to the model according to the agreed decisions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span
lang="EN-US">1.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Leaf classes without attributes and
associations to other classes<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">a.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">ControlStep, ScriptingAgent and
RulesEngine<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:108.0pt;text-indent:-9.0pt"><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">i.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Jay: they can be removed<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">b.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Sequence and Service<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:108.0pt;text-indent:-9.0pt"><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">i.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Jay: need to remain as is in line
with idea that this is a conceptual/logical model that some
but not all will use for implementation too (Smile).
<br>
Sequence is a container for other ControlConstructs and
because it inherits from ControlLogic which is reflexive
maybe Sequence can host other ControlLogic and itself.<br>
Service is an idea we would like to finish at another time.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">c.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Designation<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:108.0pt;text-indent:-9.0pt"><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">i.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Ja: Designation is another
touchpoint with Signifier, Sign and Signified<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:108.0pt;text-indent:-9.0pt"><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">ii.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Flavio: We are not using Designation
anymore<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:108.0pt;text-indent:-9.0pt"><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">iii.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Dan: Designation isn’t really needed
since we have the signification pattern. As a result, each
application of designation, whether it be a code, term, or
other, will be modeled in the realization. Designation,
being a generic term, probably is not needed.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">d.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">What is the purpose of
UnitSegmentLayout? Does it make sense for future expansion.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span
lang="EN-US">2.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">PhysicalSegmentLocation has no
attributes, only one association to ValueMapping, and only
one sub class, SegmentByText. Currently it doesn’t make much
sense. Should this be maintained for future expansion?<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span
lang="EN-US">3.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">The current approach of string types
seems to be too complicated. The structured string types
could be folded into the regular ones. Furthermore, there
are some inconsistencies.<br>
Diagrams on the current approach and the suggested approach
are attached. <o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span
lang="EN-US">4.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Missing identifiers for classes in
DataDescription, Process, and value? of a Code , see Jay’s
email on “new model version 2020-02-04 / generated files”
from 2020-02-04.<br>
Attached is a list of classes in DataDescription and
Process. The classes which inherit from Identifable are
highlighted.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span
lang="EN-US">5.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Identification and Annotation.
Identification could be an attribute not a super class
(otherwise “, annotation could be a separate class.<br>
The current model uses Identifiable and
AnnotatedIdentifiable as super classes. The Identifable is
just “Data-Based Inheritance”. There are currently 16
classes which inherit directly from Identifiable and 23
classes which inherit directly from AnnotatedIdentifiable.
There are overall 110 classes which inherit from other
classes and finally from Identifiable.<br>
The information which is captured by Identifiable can be
modeled as a data type which could be used as attribute with
the name “identifier” for each class. Even the information
which is captured by AnnotatedIdentifiable can be modeled as
a data type. The exception is the association to
AgentAssociation. There are four m:n associations from
AnnotatedIdentifiable to AgentAssociation, each with some
kind of role (publisher, contributor, versioning agent,
creator). The weird thing is that AgentAssociation itself
has again a role item (external CV).<br>
I see here some requirement for discussion how this could be
simplified. Diagrams on the current approach and one
suggested approach are attached.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">a.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">The information of Identifiable and
AnnotatedIdentifiable could be collapsed into one structured
data type with the exception of AgentAssociation.<br>
Annotation could be an attribute of Identifier. This would
be more limited than the current solution in terms of the
annotation relationship.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">b.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">Another approach would be to have
associations from classes which need Annotation. One
annotation could be then used for many classes. A related
super class could be constructed. The latter approach would
make distinction between identification (which would be an
attribute) and annotation (to which an association would
exist).<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt"><span
lang="EN-US">c.</span><span
style="font-size:7.0pt;font-family:"Times New
Roman",serif" lang="EN-US">
</span><span lang="EN-US">A third approach would be to include
the identification information in the super class described
in b). This is similar to the current approach but
Annotation is not tied to a single class. This seems to be a
flexible solution.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Achim<o:p></o:p></span></p>
</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>