<div>Hi Al,</div><div> </div><div>There were a couple of points raised with the originally proposed DataElement in 3.2PR. First that it did not allow for a CodeListReference but instead allowed for a DataElementRepresentation of type "Code" which essentially indicated it was enumerated but didn't say with what. Our initial position was that the DDI DataElement was a "stripped down" codification of 11179 and we didn't provide extensive detail. It did support the use of a Value Domain specification in the form of a CategorySchemeReference (0..1). The DataElementRepresentation was a specified list of options reflecting those noted in the earlier edition of 11179-3 (plus other...I think...I'd need to check). </div>
<div> </div><div>The argument was made that a) "Code" should not be on this list and b) CodeListReference should be allowed</div><div> </div><div>[I think the additonal points regarding the support of the direct use of DataElementConcept are not contensious]</div>
<div> </div><div>After reading the changes made in the 2012 edition of 11179-3 I felt that the differences between the use of a specific CodeList which provided enumerated representation (permitted values and link to specific concepts/category for each) and the use of "code" in a described representation was clearer.</div>
<div> </div><div>What I essentially threw out there was where we would go if we wanted something broader than the very sparse view originally provided. This seemed to be what was being requested...i.e. the ability to specify an enuemrated representation. So if I was specifying that, why not more specification to the described?</div>
<div> </div><div>I think you are correct that the first question we need to answer is what the function of DataElement is in DDI. </div><div> </div><div>This could range from:</div><div> </div><div>very narrow (remove the option for a CodeListReference and retain the DataElementRepresentation (as either an internal enumeration or an external Controlled Vocabulary...as edition 2012 leaves this pretty open) </div>
<div> </div><div>full-fledged (11179-3 with all the bells and whistles except for the administrative content)</div><div> </div><div>I think questions on the implecations for inheritance by the Variable need to be answered for either extreme as it has already been raised "why have use the ConceptReference in a Variable if you've referenced a DataElement?" </div>
<div> </div><div> </div><div>The first quesion that needs to be answered is "What is the purpose of a DDI DataElement? </div><div>I am currently agnostic on this and would like to hear from others. </div><div> </div>
<div> </div><div>Best regards,</div><div>Wendy<br></div><div class="gmail_quote">On Mon, Mar 18, 2013 at 12:27 AM, Alistair Hamilton <span dir="ltr"><<a href="mailto:alistair.hamilton@abs.gov.au" target="_blank">alistair.hamilton@abs.gov.au</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div>
<p><font face="sans-serif">Hi Wendy</font><br>
<br>
<font face="sans-serif">The following are not comments, but questions (so ABS can progress to comments).</font><br>
<br>
<font face="sans-serif">I remember talking with Arofan many months ago and he mentioned Data Elements were being added to DDI 3.2 to capture more "timeless" (eg don't change from reference period to reference period) aspects of Variables.</font><br>
<br>
<font face="sans-serif">Heather has noted that the proposed specification for Data Element has "grown" between the PDF included in the initial release of PR documentation (Doc1) and the latest document (Doc2) you circulated. This growth does not appear to be simply a symptom of the Doc2 proposal aligning with Ed 3 of 11179 (for example, ValueDomain, which is in Doc2 but not Doc1, exists in Ed 2 of 11179 also.)</font><br>
<br>
<font face="sans-serif">Whether the Doc2 proposal is overkill depends on why Data Element is being added to DDI and the expected use of it within DDI. The Doc1 specification would not allow a "fully functional" 11179 Data Element to be defined within DDI. The Doc2 specification comes a lot closer to permitting that. </font><br>
<br>
<font face="sans-serif">Then again, we still have VariableRepresentation available for a variable. Presumably providing relatively detailed Value Domain information for the DataElement (eg a CodeListReference) associated with a Variable is not an alternative to populating VariableRepresentation for the Variable itself?</font><br>
<br>
<font face="sans-serif">I quite like the Doc1 approach (and even the DataElementConcept approach in 3.1) because if an implementer has a store outside DDI that defines and manages DEs (DECs) fully in accordance with 11179 they can reference these information objects from within DDI without importing too many 11179 constructs/structures into DDI itself.</font><br>
<br>
<font face="sans-serif">If the intent were to be able to "carry around" more 11179 content within DDI, however, then the Doc2 approach supports that.</font><br>
<br>
<font face="sans-serif">There could be some merit to the Doc2 appropach - although it seems to create risks of</font>
<ul style="padding-left:18pt" type="disc">
<li><font face="sans-serif">duplication (in different forms) of information between the structural definition of the DE and the structural definition of the Variable</font>
<li><font face="sans-serif">the need for practice guidelines on, eg,</font>
<ul style="padding-left:18pt" type="disc">
<li><font face="sans-serif">the level of consistency expected between the "overlapping" structural information for CodeListReferences and VariableRepresentations</font>
<li><font face="sans-serif">the need for agencies who do focus on DataElements to populate the Variable object to a level were it will be interoperable with other DDI implementations </font></li></li></ul></li>
</li></ul>
<br>
<font face="sans-serif">Was the intent of implementing DataElement in 3.2 that DDI should be able to act as a "lite" implementation of that region of the 11179 metamodel or was it more that content in DDI should be able to integrate with an external implementation of that region of the 11179 metamodel?</font><br>
<br>
<font face="sans-serif">A "sleeper" issue also may be that the DE proposal (even in the Doc1 specification potentially) carries some information that (if DDI aligns with 11179) really belongs on an updated version of the DEC object within DDI rather than (only) being built into the new DE object. </font><br>
<br>
<font face="sans-serif">Cheers</font><br>
<br>
<font face="sans-serif">Al</font><br>
<br>
<img border="0" alt="Inactive hide details for Wendy Thomas ---15/03/2013 12:10:47 PM---Dear Dan G. Al, Heather, Arofan, Jeremy, Dan, Tim, Heather, " src="cid:1__=45BBF1A1DF8B12B38f9e8a93df938@abs.gov.au" width="16" height="16"><font color="#424282" face="sans-serif">Wendy Thomas ---15/03/2013 12:10:47 PM---Dear Dan G. Al, Heather, Arofan, Jeremy, Dan, Tim, Heather, and Sophia, As a follow-up to the earlie</font><br>
<br>
<font color="#5f5f5f" size="1" face="sans-serif">From: </font><font size="1" face="sans-serif">Wendy Thomas <<a href="mailto:wlt@umn.edu" target="_blank">wlt@umn.edu</a>></font><br>
<font color="#5f5f5f" size="1" face="sans-serif">To: </font><font size="1" face="sans-serif">"DDI Structural Reform Working Group." <<a href="mailto:ddi-srg@icpsr.umich.edu" target="_blank">ddi-srg@icpsr.umich.edu</a>>, Data Documentation Initiative Users Group <<a href="mailto:ddi-users@icpsr.umich.edu" target="_blank">ddi-users@icpsr.umich.edu</a>>, Alistair Hamilton <<a href="mailto:alistair.hamilton@abs.gov.au" target="_blank">alistair.hamilton@abs.gov.au</a>>, Heather Purcell <<a href="mailto:heather.purcell@abs.gov.au" target="_blank">heather.purcell@abs.gov.au</a>>, <a href="mailto:Tim.Dunstan@statcan.gc.ca" target="_blank">Tim.Dunstan@statcan.gc.ca</a>, Dan Gillman <<a href="mailto:gillman.daniel@bls.gov" target="_blank">gillman.daniel@bls.gov</a>>, "Kuan, Sophia [USA]" <<a href="mailto:kuan_sophia@bah.com" target="_blank">kuan_sophia@bah.com</a>>, </font><br>
<font color="#5f5f5f" size="1" face="sans-serif">Date: </font><font size="1" face="sans-serif">15/03/2013 12:10 PM</font><br>
<font color="#5f5f5f" size="1" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: Data Element Discussion - Mantis Issue 543 and related</font><br>
<hr style="color:rgb(128,145,165)" align="left" size="2" width="100%" noshade><br>
<br>
<br>
<tt><font>Dear Dan G. Al, Heather, Arofan, Jeremy, Dan, Tim, Heather, and Sophia,<br>
<br>
As a follow-up to the earlier documents trying to frame the issues<br>
around DataElement I have read through the new edition of<br>
ISO/IEC11179-3:2012(E) and provided a proposal for reworking<br>
DataElement. While I don't think this is its final form, I thought<br>
that having something concrete to react to would be useful. Please see<br>
the new documents attached to Mantis Issue 543.<br>
<br>
DataElementProposal_20130312.docx discribes the reasoning behind the<br>
outline of the proposed structure<br>
DataElementProposal.txt is a draft of an XML schema representation<br>
(note I realize there are some style issue in this rendering..its<br>
primarily to provide a draft to work with)<br>
<br>
The workplan is as follows:<br>
<br>
Provide feedback via email over the next week.<br>
Identify at the end of that time if we need a conference call. If so<br>
set one up for the following week.<br>
<br>
Please note that many of us are involved in NADDI the first week of<br>
April. As we have other issue areas that many of you are also<br>
interested in I am hoping to get this one moving along. The intent is<br>
not to cut short discussion, but to allow us to focus on a topic at a<br>
time. I appreciate your attention to this. Hope to hear responses over<br>
the next week.<br>
<br>
Primary questions to answer include:<br>
<br>
Does this address the issues identified in the document provided earlier?<br>
Is it compliant with ISO/IEC 11179-3:2012(E)?<br>
Does it meet the needs of DDI?<br>
Is it overkill?<br>
<br>
I expect a lively discussion :-)<br>
<br>
Wendy<br>
<br>
<br>
<br>
On Sun, Feb 24, 2013 at 5:20 PM, Wendy Thomas <<a href="mailto:wlt@umn.edu" target="_blank">wlt@umn.edu</a>> wrote:<br>
> Dan G., Al, Heather, Arofan, Achim, Jeremy and Dan,<br>
><br>
> I have tried to frame the issues regarding the introduction of a<br>
> DataElement in DDI based on earlier discussions and a review of<br>
> ISO/IEC 11179-3. You will find a document on Mantis Issue 543 entitled<br>
> Purpose of DataElement in DDI.docx. Please review this document and<br>
> make comments back to the list. There are a number of issues in 3.2PR<br>
> that need in-depth discussion. DataElement is the first of these. Our<br>
> intent is to begin an on-line discussion among interested parties,<br>
> attempt to find an area of concensus and then set up conference calls<br>
> to finalize the details. Please note that this email has been copied<br>
> to the DDI-SRG list and DDI-Users list in order to inform others of<br>
> this discussion and to identify persons who should be involved further<br>
> in the discussion.<br>
><br>
> To DDI-SRG and DDI-User list members: If you have a vested interest in<br>
> how this new section of DDI is addressed in 3.2 PR, please let me know<br>
> and I will add you to the contact list. Note that we are dealing with<br>
> fine tuning what was proposed in DDI 3.2PR and therefore you will need<br>
> to have a familiarity with ISO/IEC 11179-3 and/or the maintenance of<br>
> DataElements for these discussions to be of benefit to you and to DDI.<br>
> Having said that, I wish you to know that I am very happy to address<br>
> any specific questions or related issues you may have with this<br>
> discussion of DataElements.<br>
><br>
> Regards<br>
> Wendy<span class="HOEnZb"><font color="#888888"><br>
><br>
> --<br>
> Wendy L. Thomas Phone: +1 612.624.4389<br>
> Data Access Core Director Fax: +1 612.626.8375<br>
> Minnesota Population Center Email: <a href="mailto:wlt@umn.edu" target="_blank">wlt@umn.edu</a><br>
> University of Minnesota<br>
> 50 Willey Hall<br>
> 225 19th Avenue South<br>
> Minneapolis, MN 55455<br>
<br>
<br>
<br>
-- <br>
Wendy L. Thomas Phone: +1 612.624.4389<br>
Data Access Core Director Fax: +1 612.626.8375<br>
Minnesota Population Center Email: <a href="mailto:wlt@umn.edu" target="_blank">wlt@umn.edu</a><br>
University of Minnesota<br>
50 Willey Hall<br>
225 19th Avenue South<br>
Minneapolis, MN 55455<br>
</font></span></font></tt><span class="HOEnZb"><font color="#888888"><br>
<p><span style="font-family:"Arial";font-size:8pt">-----------------------------------------------------------------------------------------------</span></p>
<p><span style="font-family:"Arial";font-size:8pt">Free publications and statistics available on <a href="http://www.abs.gov.au" target="_blank">www.abs.gov.au</a></span></p>
<p><span style="font-family:"Arial";font-size:9pt"> </span></p></font></span><p></p></p></div>
</blockquote></div><br><br clear="all"><br>-- <br><div>Wendy L. Thomas Phone: +1 612.624.4389</div><div>Data Access Core Director Fax: +1 612.626.8375</div><div>Minnesota Population Center Email: <a href="mailto:wlt@umn.edu" target="_blank">wlt@umn.edu</a></div>
<div>University of Minnesota</div><div>50 Willey Hall</div><div>225 19th Avenue South</div><div>Minneapolis, MN 55455</div>