-
Notifications
You must be signed in to change notification settings - Fork 0
/
training_1.html
1127 lines (1037 loc) · 41 KB
/
training_1.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
<title>Documentation</title>
<script src="site_libs/header-attrs-2.16/header-attrs.js"></script>
<script src="site_libs/jquery-3.6.0/jquery-3.6.0.min.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link href="site_libs/bootstrap-3.3.5/css/flatly.min.css" rel="stylesheet" />
<script src="site_libs/bootstrap-3.3.5/js/bootstrap.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/html5shiv.min.js"></script>
<script src="site_libs/bootstrap-3.3.5/shim/respond.min.js"></script>
<style>h1 {font-size: 34px;}
h1.title {font-size: 38px;}
h2 {font-size: 30px;}
h3 {font-size: 24px;}
h4 {font-size: 18px;}
h5 {font-size: 16px;}
h6 {font-size: 12px;}
code {color: inherit; background-color: rgba(0, 0, 0, 0.04);}
pre:not([class]) { background-color: white }</style>
<script src="site_libs/jqueryui-1.11.4/jquery-ui.min.js"></script>
<link href="site_libs/tocify-1.9.1/jquery.tocify.css" rel="stylesheet" />
<script src="site_libs/tocify-1.9.1/jquery.tocify.js"></script>
<script src="site_libs/navigation-1.1/tabsets.js"></script>
<link href="site_libs/highlightjs-9.12.0/default.css" rel="stylesheet" />
<script src="site_libs/highlightjs-9.12.0/highlight.js"></script>
<script defer data-domain="cghlewis.github.io/mpsi-data-training" src="https://plausible.io/js/plausible.js"></script>
<style type="text/css">
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
</style>
<style type="text/css">code{white-space: pre;}</style>
<script type="text/javascript">
if (window.hljs) {
hljs.configure({languages: []});
hljs.initHighlightingOnLoad();
if (document.readyState && document.readyState === "complete") {
window.setTimeout(function() { hljs.initHighlighting(); }, 0);
}
}
</script>
<link rel="stylesheet" href="css/custom.css" type="text/css" />
<style type = "text/css">
.main-container {
max-width: 940px;
margin-left: auto;
margin-right: auto;
}
img {
max-width:100%;
}
.tabbed-pane {
padding-top: 12px;
}
.html-widget {
margin-bottom: 20px;
}
button.code-folding-btn:focus {
outline: none;
}
summary {
display: list-item;
}
details > summary > p:only-child {
display: inline;
}
pre code {
padding: 0;
}
</style>
<style type="text/css">
.dropdown-submenu {
position: relative;
}
.dropdown-submenu>.dropdown-menu {
top: 0;
left: 100%;
margin-top: -6px;
margin-left: -1px;
border-radius: 0 6px 6px 6px;
}
.dropdown-submenu:hover>.dropdown-menu {
display: block;
}
.dropdown-submenu>a:after {
display: block;
content: " ";
float: right;
width: 0;
height: 0;
border-color: transparent;
border-style: solid;
border-width: 5px 0 5px 5px;
border-left-color: #cccccc;
margin-top: 5px;
margin-right: -10px;
}
.dropdown-submenu:hover>a:after {
border-left-color: #adb5bd;
}
.dropdown-submenu.pull-left {
float: none;
}
.dropdown-submenu.pull-left>.dropdown-menu {
left: -100%;
margin-left: 10px;
border-radius: 6px 0 6px 6px;
}
</style>
<script type="text/javascript">
// manage active state of menu based on current page
$(document).ready(function () {
// active menu anchor
href = window.location.pathname
href = href.substr(href.lastIndexOf('/') + 1)
if (href === "")
href = "index.html";
var menuAnchor = $('a[href="' + href + '"]');
// mark the anchor link active (and if it's in a dropdown, also mark that active)
var dropdown = menuAnchor.closest('li.dropdown');
if (window.bootstrap) { // Bootstrap 4+
menuAnchor.addClass('active');
dropdown.find('> .dropdown-toggle').addClass('active');
} else { // Bootstrap 3
menuAnchor.parent().addClass('active');
dropdown.addClass('active');
}
// Navbar adjustments
var navHeight = $(".navbar").first().height() + 15;
var style = document.createElement('style');
var pt = "padding-top: " + navHeight + "px; ";
var mt = "margin-top: -" + navHeight + "px; ";
var css = "";
// offset scroll position for anchor links (for fixed navbar)
for (var i = 1; i <= 6; i++) {
css += ".section h" + i + "{ " + pt + mt + "}\n";
}
style.innerHTML = "body {" + pt + "padding-bottom: 40px; }\n" + css;
document.head.appendChild(style);
});
</script>
<!-- tabsets -->
<style type="text/css">
.tabset-dropdown > .nav-tabs {
display: inline-table;
max-height: 500px;
min-height: 44px;
overflow-y: auto;
border: 1px solid #ddd;
border-radius: 4px;
}
.tabset-dropdown > .nav-tabs > li.active:before {
content: "";
font-family: 'Glyphicons Halflings';
display: inline-block;
padding: 10px;
border-right: 1px solid #ddd;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li.active:before {
content: "";
border: none;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open:before {
content: "";
font-family: 'Glyphicons Halflings';
display: inline-block;
padding: 10px;
border-right: 1px solid #ddd;
}
.tabset-dropdown > .nav-tabs > li.active {
display: block;
}
.tabset-dropdown > .nav-tabs > li > a,
.tabset-dropdown > .nav-tabs > li > a:focus,
.tabset-dropdown > .nav-tabs > li > a:hover {
border: none;
display: inline-block;
border-radius: 4px;
background-color: transparent;
}
.tabset-dropdown > .nav-tabs.nav-tabs-open > li {
display: block;
float: none;
}
.tabset-dropdown > .nav-tabs > li {
display: none;
}
</style>
<!-- code folding -->
<style type="text/css">
#TOC {
margin: 25px 0px 20px 0px;
}
@media (max-width: 768px) {
#TOC {
position: relative;
width: 100%;
}
}
@media print {
.toc-content {
/* see https://github.com/w3c/csswg-drafts/issues/4434 */
float: right;
}
}
.toc-content {
padding-left: 30px;
padding-right: 40px;
}
div.main-container {
max-width: 1200px;
}
div.tocify {
width: 20%;
max-width: 260px;
max-height: 85%;
}
@media (min-width: 768px) and (max-width: 991px) {
div.tocify {
width: 25%;
}
}
@media (max-width: 767px) {
div.tocify {
width: 100%;
max-width: none;
}
}
.tocify ul, .tocify li {
line-height: 20px;
}
.tocify-subheader .tocify-item {
font-size: 0.90em;
}
.tocify .list-group-item {
border-radius: 0px;
}
</style>
</head>
<body>
<div class="container-fluid main-container">
<!-- setup 3col/9col grid for toc_float and main content -->
<div class="row">
<div class="col-xs-12 col-sm-4 col-md-3">
<div id="TOC" class="tocify">
</div>
</div>
<div class="toc-content col-xs-12 col-sm-8 col-md-9">
<div class="navbar navbar-default navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-bs-toggle="collapse" data-target="#navbar" data-bs-target="#navbar">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html"></a>
</div>
<div id="navbar" class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li>
<a href="index.html">About</a>
</li>
<li>
<a href="training_00.html">Data Management</a>
</li>
<li>
<a href="training_0.html">Project Management</a>
</li>
<li>
<a href="training_1.html">Module 1</a>
</li>
<li>
<a href="training_2.html">Module 2</a>
</li>
<li>
<a href="training_3.html">Module 3</a>
</li>
<li>
<a href="training_4.html">Module 4</a>
</li>
<li>
<a href="training_5.html">Module 5</a>
</li>
<li>
<a href="training_6.html">Module 6</a>
</li>
</ul>
<ul class="nav navbar-nav navbar-right">
</ul>
</div><!--/.nav-collapse -->
</div><!--/.container -->
</div><!--/.navbar -->
<div id="header">
<h1 class="title toc-ignore">Documentation</h1>
</div>
<p><br></p>
<div class="presentation">
<p><br> You can view slides from this talk <a
href="https://cghlewis.github.io/mpsi-training1/">here</a>.</p>
</div>
<hr />
<div id="overview" class="section level2">
<h2>Overview</h2>
<hr />
<p>Data documentation is not only required by funders including IES, it
is essential for data management. Data documentation should cover the
who, what, where, when, and why of your project and your data (<a
href="https://osf.io/48ufs/">OSF: NIH</a>).</p>
<p><img src="img/document2.PNG" width="65%" style="display: block; margin: auto;" /></p>
<p>Documentation also allows you to:</p>
<ul>
<li>Track decisions/changes made throughout the life cycle of the
project<br />
</li>
<li>Make decisions/analyses replicable<br />
</li>
<li>Clean data with fidelity<br />
</li>
<li>Ensure others use and interpret data accurately<br />
</li>
<li>Discover errors in data<br />
</li>
<li>Allow others to find archived data through metadata</li>
<li>Reduces <a
href="https://www.teaguehenry.com/strings-not-factors/2021/1/24/data-management-for-researchers-three-terrifying-tales">data
rot</a>, when good data is transformed over time and becomes unusable
because no one tracks the transformation</li>
</ul>
<p>Documentation can take many forms. <a
href="https://ies.ed.gov/funding/datasharing_implementation.asp">IES</a>
states that they expect documentation to “be a comprehensive and
stand-alone document that includes all the information necessary to
replicate the analysis performed by the original research team” and
should include:</p>
<ul>
<li>a summary of the purpose of the data collection<br />
</li>
<li>methodology and procedures used to collect the data<br />
</li>
<li>timing of the data collection<br />
</li>
<li>details of the data codes, definition of variables, transformations,
variable field locations, and frequencies</li>
</ul>
<p>However, a) IES provides no template for how documentation is laid
out OR what tools to use to create/share this information and b) outside
of IES required documentation for data sharing, there may be additional
documentation your team may want to keep to help manage internal
processes.</p>
<p>This training will cover types of documentation you may want to keep.
Many of these documents have overlapping information and some terms may
be used interchangeably in the field (ex: Data dictionary and codebook
or README and metadata). Also, some of the documents are important to
start day one of the project, while others are more important to create
at the end of the project when you are ready to share data. The point of
this next section isn’t to implement all of these documents, but rather
to consider which documents capture the information you need to have a
successful project. It may just be a protocol and a data dictionary. Or
it may be a protocol, a data dictionary and a README for each data file.
Or it may be all of these documents! It depends on things such as the
scale of your project and how you plan to share the data at the end of
your project.</p>
<p>Additional reading on the importance of data documentation can be
found here:</p>
<p>📑 <a
href="https://www.helsinki.fi/en/research/guide-for-data-documentation">University
of Helsinki</a><br />
📑 <a
href="https://libguides.wustl.edu/c.php?g=47355&p=303435">Washington
University in St. Louis</a></p>
<hr />
</div>
<div id="documentation" class="section level2">
<h2>Documentation</h2>
<hr />
<div id="protocol" class="section level3">
<h3>Protocol</h3>
<p>I’ve seen this document called many other names including procedures
manual, standard operation procedures (sop), research protocol, or
coordinator’s manual. The CITI Good Clinical Practices <a
href="https://about.citiprogram.org/series/good-clinical-practice-gcp/">training</a>
calls this a Clinical Protocol. Whatever term you use, this is a
document/s to record all of your procedures and changes made to those
procedures throughout the grant.</p>
<p>At some point someone will ask you how or why you did something the
way you did. This is the document that will save you because it is very
likely that you will not remember. This document also helps standardize
your procedures. You can and should refer back to this document during a
longitudinal study to ensure you continue to implement procedures in the
same way.</p>
<p>I highly recommend always adding protocol as part of any data
documentation plan. You can make separate protocol documents per
procedure or keep them all in one standalone document with a table of
contents. Most likely your protocol will not be shared outside of your
team, but the information in your protocol can be used to inform other
documentation such as READMEs or codebooks. Your protocol can live in
any format that works for you (ex: .docx, .md, .txt, google doc, or you
can use a platform such as <a
href="https://www.protocols.io/">protocols.io</a>). It is a living
document that will be continually updated so use a format that makes
sense for you. All of your project/grant specific protocols should be
housed in an easily accessible location such as the top of a project
folder.</p>
<p>It is also possible to have protocols that may be applicable across
all projects (such as rules for data entry). You can keep a copy of
these more broad rules in an institutional protocol (or some may call it
a lab manual) to be referred to for all projects and keep it in an
accessible location such as your team folder.</p>
<p>Protocol should cover procedures/decisions for the following:</p>
<ul>
<li>Participant recruitment (inclusionary and exclusionary
decisions)</li>
<li>Consent and assent</li>
<li>Participant selection</li>
<li>Randomization and blinding/unblinding</li>
<li>Data collection</li>
<li>Staff training</li>
<li>Data entry, data retrieval, data scoring (including decision
rules)</li>
<li>Payments/incentives</li>
<li>Intervention implementation</li>
</ul>
<p>Each protocol should <em>begin</em> with the following:</p>
<ul>
<li>Title</li>
<li>Date the protocol was made</li>
<li>Who made the protocol</li>
<li>Any rationale behind the protocol</li>
<li>Any related documents or research behind the protocol</li>
</ul>
<p>There may be times when you need to revise your protocol, either due
to decisions made by the researchers (ex: moving surveys from paper to
online due to the pandemic) or to note deviations from the protocol
discovered during data collection (ex: data collectors were allowing
students to read assessment instructions on their own rather than
reading them out loud to the group). For any <em>changes to</em> or
<em>deviations from</em> the protocol after the project has begun, add
the following below the original protocol section:</p>
<ul>
<li>Revision Date<br />
</li>
<li>Who decided on the revision<br />
</li>
<li>Any rationale behind the revision<br />
</li>
<li>Any related documents or research behind the revision</li>
</ul>
<p>It is also good practice to add a copy of your data collection
instruments to your protocol (Surveys, Interview Questions, etc.), as
well as changes/versions of those and explanations for the changes.</p>
<p>📑 These <a
href="https://figshare.com/articles/Data_Management_and_Data_Management_Plans/7890827">slides</a>
from Jessica Logan, Ph.D. have nice protocol examples.<br />
📑 This <a href="img/sample_sop.pdf">sample</a> protocol (or sop) from
CITI, while not education focused, provides a nice template for how to
lay out each individual protocol.<br />
📑 This is a cool <a
href="https://cds-snc.github.io/design-research-handbook/home/">example</a>
of an interactive research protocol housed on GitHub. You could build
something similar in a tool like Google Docs. While this one isn’t
education specific, you can see how the outline can be replaced with
education research content.</p>
<p><br></p>
</div>
<div id="style-guide" class="section level3">
<h3>Style Guide</h3>
<p>A <a href="https://en.wikipedia.org/wiki/Style_guide">style guide</a>
is a set of standards around data management rules. It improves
consistency within and across files and projects. This document includes
conventions for procedures such as variable naming, value coding, file
naming, versioning, and file structure. Consider having a style guide
specific to every project (for variable naming, value coding) as well as
a general style guide that applies to all projects (for file structure,
versioning, and file naming). This guide can be be kept in any form such
as .txt or .pdf and should be housed where it can easily be accessed by
all team members (Ex: a style guide that applies across projects may be
kept on a wiki and a project-specific style guide may be kept as a
protocol or README in a project folder). See <a
href="https://cghlewis.github.io/mpsi-data-training/training_3.html">Training3</a>
for best practices in style guides.</p>
<p>Example <a
href="https://github.com/bartvandebiezen/file-name-conventions/blob/master/README.md">style
guide</a>.</p>
<p><br></p>
</div>
<div id="wiki" class="section level3">
<h3>Wiki</h3>
<p>I am including a wiki in this list even though I think it is an
unconventional documentation tool in education research. A wiki can help
your team internally document, organize, and navigate reference
material. If you use platforms such as Microsoft SharePoint, your
default team page type is wiki and your home page can be a great place
to store information that your team frequently refers to. SharePoint
describes a wiki as “a site that is designed for groups of people to
quickly capture and share ideas by creating simple pages and linking
them together.” It is a page that anyone on your team can add/edit
content (a short blurb about the document) and then can link to those
referenced documents for easy access.</p>
<p>Wikis can be made for specific research projects and are great for
referring to frequently requested information (ex: recruitment
information or participant payment details). You can also make a general
research team wiki that includes information that either applies to your
entire team (ex: Team meeting notes or employee manual) or information
that is relevant across all projects (ex: Style guide, lab manual).</p>
<p>📑 You can make wikis with many other tools, but you can read more
about SharePoint’s wiki <a
href="https://support.microsoft.com/en-us/office/create-and-edit-a-wiki-dc64f9c2-d1a2-44b5-ac59-b9d535551a32">here</a>.</p>
<p>📑 <a
href="https://www.notion.so/guides/how-to-build-a-wiki-for-your-company">Notion</a>
is another tool I recently learned of to build a wiki as well.</p>
<p>📑 There is a great episode of the <a
href="https://www.buzzsprout.com/1074286/5185513-episode-5-organizing-shared-network-drives-tips-and-tricks">Education
Data Chat</a> podcast where they discuss wikis as well.</p>
<p><br></p>
</div>
<div id="data-dictionary" class="section level3">
<h3>Data Dictionary</h3>
<p>A data dictionary is another essential data management document and I
highly suggest you start this before your ever collect a piece of data.
This will help you set up successful back-end coding as you create data
collection tools and it will serve as a reference document you can use
as questions come up about the data. It is also a document that can be
shared with others to help them better understand your data. A data
dictionary is usually in rectangular format, for example an Excel
spreadsheet, Google sheet or something similar that has rows and
columns. It includes all information relevant to every variable in your
data.</p>
<p>📑 Here is a nice <a
href="https://media.screensteps.com/image_assets/assets/001/878/671/original/8fbcc565-602f-4ac6-b828-2eaaeb67578b.png">example</a>
of a very simple data dictionary.</p>
<p>Your dictionary <strong>should</strong> capture information such
as:</p>
<ul>
<li>Variable Name<br />
</li>
<li>Variable Label<br />
</li>
<li>Exact question text<br />
</li>
<li>Associated scale/measure (if the item belongs to a scale)</li>
<li>Associated form (Student survey, teacher rating of student,
etc.)</li>
<li>Value range or value codes ([1-99] or 0=No, 1=Yes)<br />
</li>
<li>Measurement unit (numeric, string, date, etc.)<br />
</li>
<li>Missing data codes</li>
<li>Variable universe (Who gets this question? Is there skip
logic?)</li>
<li>What time periods does this variable exist</li>
<li>Reverse coding</li>
<li>Calculations (composite variables, scores)</li>
<li>Notes (such as versions/changes to this variable)</li>
<li>Question number (order number of the question on the measure)</li>
</ul>
<p>You may consider having separate data dictionaries per expected final
dataset. So for example, if you plan to have a final teacher dataset and
a final student dataset, you may want to have a student dictionary and a
teacher dictionary rather than having only one data dictionary and
marking teacher or student in the universe column.</p>
<p>As I mentioned earlier, it is important to start a data dictionary
<strong>before</strong> ever collecting data. You should be able to
begin filling in information for the data you have control over. For
example, if you are making and administering the survey, you should be
able to know what variables will be in that data, how you want to name
them, and how they should be coded. However, you may not know this
information for other variables until after data collection. For
example, if you are administering a 3rd party assessment, you may not
know what the exported data is going to look like until after you have
collected the data and it has been scored. Just remember, this is a
living document that will updated continually throughout the life of the
project.</p>
<p><strong>In order to start a data dictionary, you should gather the
following information</strong>:</p>
<ul>
<li>What measures are we collecting? (Ex: Student Assessment, Teacher
Observation, Teacher Survey, Principal Interview)</li>
<li>What are the items/scales included?</li>
<li>What is your variable naming protocol? (See <a
href="https://cghlewis.github.io/mpsi-data-training/training_3.html#Variable_Naming">variable
naming in Style Guide</a>)</li>
<li>Do your items/scales have pre-determined value coding rules or can
we assign our own? What is our value coding protocol? (See <a
href="https://cghlewis.github.io/mpsi-data-training/training_3.html#Value_Coding">value
coding in Style Guide</a>)</li>
</ul>
<p>It’s good to also consider starting to document the variables you
aren’t collecting but you are <strong>assigning</strong> or
<strong>deriving</strong>.</p>
<ul>
<li>Variables you are assigning:
<ul>
<li>To maintain anonymity and to track participants and merge data over
time, you will be assigning identifiers.
<ul>
<li>Participant/Study ID (<em>stu_id</em>, <em>tch_id</em>)</li>
<li>Location/Site ID (<em>sch_id</em>, <em>dist_id</em>)</li>
</ul></li>
<li>Depending on your study design you may also need to account for the
following:
<ul>
<li>Treatment/condition/intervention group (Ex: <em>int</em>)</li>
<li>Time/wave (<em>year</em>, <em>wave</em>, <em>cohort</em>)</li>
<li>Randomization blocks (<em>class</em>, <em>group</em>)</li>
</ul></li>
</ul></li>
<li>Variables you derive:
<ul>
<li>These include things such as composite scores, weights, or
continuous variables grouped into categories. You can start to add these
variables and their calculations/logic to your data dictionary.
<ul>
<li>Ex: <em>scale_mean</em>, <em>sch_size_cat</em></li>
</ul></li>
</ul></li>
</ul>
<div class="question">
<p><strong>Quick thought: Accounting for Time</strong></p>
<p>When deciding how to account for time, consider how you plan to merge
your data across time.</p>
<ol style="list-style-type: lower-alpha">
<li>Merge wide (each row is a unique participant and all associated time
points are in that row), then append time to your variables (prefix or
suffix) <br></li>
<li>Merge long (a unique participant occurs in multiple rows for each
time period collected), then time can be its own variable/s</li>
</ol>
</div>
<p><br></p>
<p>Additional reading on data dictionaries can be found here:</p>
<p>📑 <a
href="https://help.osf.io/hc/en-us/articles/360019739054-How-to-Make-a-Data-Dictionary">OSF</a><br />
📑 <a
href="https://data.nal.usda.gov/data-dictionary-purpose">USDA</a><br />
📑 <a
href="https://www.helsinki.fi/en/research/guide-for-data-documentation#section-72708">University
of Helsinki</a><br />
📑 <a href="http://kbroman.org/dataorg/pages/dictionary.html">Karl
Broman</a><br />
📑 <a href="https://www.methodology.psu.edu/ra/most/redcap/">Penn
State</a><br />
📑 <a href="https://www.eddatadoneright.com/">Education Data Done
Right</a></p>
<p><br></p>
</div>
<div id="codebook" class="section level3">
<h3>Codebook</h3>
<p>Like a data dictionary, a codebook also captures variable
information, as well as project level information. It should capture all
a user would need to know in order to understand and correctly interpret
your data. It is typically part of the metadata that is added to a data
archive, or is given to those who request your data after the project is
complete. It usually takes the form of a plain text file (.txt), pdf
(.pdf), or extensible markup language (.xml), rather than a proprietary
form such as .docx. If you embed metadata into your data, such as
variable labels, value labels and missing values, several statistical
programs (including R, SPSS, SAS and Stata) will export codebooks for
your final datasets. You can make one large codebook that includes all
data for your project, or make separate codebooks by dataset (ex:
Teacher level dataset codebook), or even by measure (ex: Student survey
codebook).</p>
<p>📑 Here is a nice example of a <a
href="https://ddialliance.org/sites/default/files/06551.pdf">codebook</a>.</p>
<p>Your codebook should captures things such as:</p>
<ul>
<li>Study title<br />
</li>
<li>Names of Investigators<br />
</li>
<li>Table of contents<br />
</li>
<li>Purpose and format of the codebook<br />
</li>
<li>Variable level details
<ul>
<li>Variable name<br />
</li>
<li>Variable label<br />
</li>
<li>Question text<br />
</li>
<li>Measurement unit</li>
<li>Coded values or value range (1,2,3,4)<br />
</li>
<li>Value labels (<em>excellent</em>, <em>good</em>, <em>fair</em>,
<em>poor</em>)<br />
</li>
<li>Summary statistics</li>
<li>Missing data values<br />
</li>
<li>Skip patterns<br />
</li>
<li>Notes<br />
</li>
<li>If data is in text format, indicate position of each variable</li>
</ul></li>
<li>Computations</li>
<li>Imputations</li>
</ul>
<p>Other optional content for a codebook:</p>
<ul>
<li>Citations for scales used and published reliability</li>
<li>Data collection instruments</li>
<li>Consent agreements</li>
<li>Methodological details<br />
</li>
<li>Flowchart of data collection instruments/screeners</li>
<li>Study timeline</li>
</ul>
<p><em>Last, I have found that sometimes the term data dictionary is
synonymous with codebook. I don’t think the name matters, but for the
sake of this training I am specifying a data dictionary as the document
in tabular form with only variable level information and a codebook as a
document usually in text format. You can keep either or both types of
documentation. I think the data dictionary as laid out in this training
is the easier document to update throughout the life of the project and
assists with project implementation, while I view the codebook as a
document to summarize the final datasets at the end of the project (and
to be included with data archives/requests).</em></p>
<p>Further information on codebooks can be found here:</p>
<p>📑 <a
href="https://www.icpsr.umich.edu/icpsrweb/content/shared/ICPSR/faqs/what-is-a-codebook.html">ICPSR</a><br />
📑 <a
href="https://www.datafiles.samhsa.gov/faq/what-codebook-nid3440">SAMHDA</a><br />
📑 <a
href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjb8-TwpMPsAhUM2qwKHXFdB1cQFjAKegQIBBAC&url=https%3A%2F%2Fosf.io%2F72hrh%2F%3Faction%3Ddownload%26version%3D2&usg=AOvVaw340qQlC9mDMzc444K_dkhT">Kai
Horstmann</a><br />
📑 <a href="https://rubenarslan.github.io/codebook/index.html">The R
package Codebook</a></p>
<p><br></p>
</div>
<div id="readme" class="section level3">
<h3>README</h3>
<p>A README is a plain text (.txt), markdown (.md), pdf (.pdf), or
extensible markup language (.xml), standalone file that explains your
files. README files are most known for their use in programming, but
have become more prevalent in research. It is recommended to make one
README file per dataset. This standalone document will accompany each
dataset. It should be named so it is easily associated with the dataset
and it should be housed in the same folder the data is in.</p>
<p>A README should capture data such as:</p>
<ul>
<li>General information (Title of dataset, contact information, key
dates, funding)</li>
<li>File information (Description, format, creation date, versions)</li>
<li>Access information (Licenses, recommended citation, associated
publications)</li>
<li>Methodology (Consent rates, data collection methods, data processing
methods, software used, quality-assurance procedures)</li>
<li>Optional: Your codebook can also be part of your README, rather than
a separate document
<ul>
<li>Here is an <a
href="https://libguides.wustl.edu/ld.php?content_id=29108244">example</a></li>
</ul></li>
</ul>
<p>Excellent examples, templates, and further details can be found
here:</p>
<p>📑 <a href="https://osf.io/y2gjr/">README with Codebook included:
University of Munster</a><br />
📑 <a
href="https://guides.library.oregonstate.edu/ld.php?content_id=45294345">README
template: Oregon State</a><br />
📑 <a href="https://cornell.app.box.com/v/ReadmeTemplate">README
template: Cornell</a><br />
📑 <a href="https://osf.io/sj8xv/">README template: OSF</a><br />
📑 <a href="https://guides.lib.uci.edu/datamanagement/readme">README
recommended content: UCI</a><br />
📑 <a href="https://data.research.cornell.edu/content/readme">README
recommended content: Cornell</a><br />
📑 <a href="https://libguides.graduateinstitute.ch/rdm/readme">README
recommended content: IHEID</a></p>
<p><br></p>
</div>
<div id="metadata" class="section level3">
<h3>Metadata</h3>
<p>Metadata is <em>data about data</em>. They are structured data that
“provide information about the dataset to help people find, understand,
and use your data” (<a
href="https://ies.ed.gov/funding/datasharing_faq.asp">IES</a>). Most of
the time when you hear the term metadata, it will be referring to what I
am going to call project-level metadata.</p>
<ol style="list-style-type: decimal">
<li>Project-level metadata is a type of descriptive and legal metadata
that aids in finding your project through internet searches. It is like
the “label of the dataset”. At minimum the information captured should
include who created the data, when the data were created, a title and
description of the data, and a unique identifier for the data. This is
the type of data we discussed capturing earlier within the
<em>General</em>, <em>File</em>, and <em>Access</em> portion of our
<em>README</em> files.</li>
</ol>
<p>Common elements of project-level metadata include:</p>
<p><img src="img/metadata.PNG" width="80%" style="display: block; margin: auto;" />
Source: <a
href="https://libguides.up.edu/datamanagement/documentation">University
of Portland</a></p>
<p>Metadata can also also be categorized further into data-level and
variable-level:</p>
<ol start="2" style="list-style-type: decimal">
<li><p>Data-level metadata, which might be considered administrative or
technical metadata, focuses more on the details of each dataset such as
instruments used to collect the data and software used to process the
data. Lucikly, creating this metadata requires no extra effort because
this is the exact information captured in sections like
<em>Methodology</em> in your <em>README</em> files above.</p></li>
<li><p>Variable-level metadata, which might be considered structural
metadata, is data about the variables in your dataset. This can be both
incorporated into your data, by adding attributes like variable and
value labels, as well as accounted for externally, and it is includes
all the information discussed earlier in your <em>codebook</em> and/or
<em>data dictionary</em>. This data should also describe how datasets
relate to one another (ex: student dataset is linked to teacher dataset
through tch_id). If your data is qualitative in nature (such as
documents, photos, videos, or sound files), metadata such as
date/time/location, tags/keywords, or measurement information can
sometimes be embedded directly into your files (<a
href="https://libguides.graduateinstitute.ch/rdm/qualitative">IHEID</a>).</p></li>
</ol>
<p>The most notable thing about metadata is that many fields follow
metadata standards that aid in the “retrieving and indexing” of your
data (<a
href="https://data.library.arizona.edu/best-practices/data-documentation-readme-metadata">University
of Arizona</a>). Standards include things such as agreed upon formats,
vocabularies, and structure. For example social science often follows
the Data Documentation Initiative (<a
href="https://ddialliance.org/">DDI</a>) standards. However, (<a
href="https://ies.ed.gov/funding/datasharing_faq.asp">IES</a>) states
that education has no standards and that instead “researchers should
document everything and strive to make notation as interpretable as
possible”. Metadata can either be embedded within data or included in a
separate file such as a README.txt or .pdf file.</p>
<p>If you plan to archive your data, the data repository you plan to use
may have standards in place that you will need to follow. Consult your
repository’s website for detailed information on what is required for
archival. Many universities have archives that are available for use and
IES also has recommended data repositories that can be found <a
href="https://ies.ed.gov/funding/datasharing_faq.asp">here</a>.</p>
<p>Additional metadata information can be found here:</p>
<p>📑 <a
href="https://guides.library.oregonstate.edu/research-data-services/data-management-metadata#:~:text=Project%2Dlevel%20metadata%20describes%20the,Dataset%20title">Oregon
State</a><br />
📑 <a
href="https://guides.lib.uci.edu/datamanagement/describe">UCI</a><br />
📑 <a
href="https://www.lib.ncsu.edu/do/data-management/metadata">NCSU</a><br />
📑 <a
href="https://www.icpsr.umich.edu/web/pages/datamanagement/dmp/plan.html">ICPSR</a><br />
📑 <a
href="https://ddialliance.org/training/getting-started/data-catalog">DDI</a><br />
📑 <a
href="https://guides.archaeologydataservice.ac.uk/g2gp/CreateData_1-2#ref-CreateData_1-2-9">ADS</a><br />
📑 <a
href="https://www.helsinki.fi/en/research/guide-for-data-documentation">University
of Helsinki</a><br />
📑 <a
href="https://www.lse.ac.uk/library/research-support/research-data-management/metadata-and-documentation">London
School of Economics and Political Science</a><br />
📑 <a
href="https://libguides.wustl.edu/c.php?g=47355&p=305263">Washington
University in St. Louis</a><br />
📑 <a
href="https://pelagicpublishing.com/products/data-management-for-researchers-briney">Data
Management for Researchers</a><br />
📑 <a href="https://dmptool.org/general_guidance">DMP Tool General
Guidance</a><br />
📑 <a
href="https://www.cessda.eu/Training/Training-Resources/Library/Data-Management-Expert-Guide/2.-Organise-Document/Documentation-and-metadata">CESSDA</a><br />
📑 <a href="https://libguides.wustl.edu/drmr/dataprep">Washington
University</a><br />
📑 <a href="https://zenodo.org/record/3534954#.YFIxBZ1KiUk">Jessica
Rex</a></p>
<p><br></p>
</div>
<div id="miscellaneous" class="section level3">
<h3>Miscellaneous</h3>
<p>Last you should consider documenting <strong>all</strong> your data
processes to allow for reproducibility. This may fit into one of the
above mentioned documents, or it may be a separate text or markdown
files (such as a README), a syntax file, or even an Excel file. Keep
this document in the folder related to the content and name it
accordingly. Consider tracking things such as:</p>
<ul>
<li><p>Versioning (Ex:
<code>README_district-file-changelog.txt</code>):</p>
<ul>
<li>If you use version control, this is easy to track through commit
messages or commenting. However, if you do not use software that has
version control, consider keeping a document, such as a changelog, that
tracks differences between files.
<ul>
<li><code>district-data_2020-10-02.xlsx</code>: File received from
District A containing 2019-20 test scores</li>
<li><code>district-data_2020-10-03.xlsx</code>: File received from
District A with 5 additional students added after
<code>district-data_2020-10-02.xlsx</code> was received</li>
<li><code>district-data_2020-10-04.xlsx</code>: File received form
District A with test scores updated for 30 students because errors were
found in <code>district-data_2020-10-03.xlsx</code><br />
<br></li>
</ul></li>
</ul></li>
<li><p>Data cleaning plan (Ex:
<code>district_data-cleaning-plan.md</code>)</p>
<ul>
<li>This will be discussed more in later trainings, but a written
analysis plan can be helpful to communicate across your team, as a
reminder to your future self, and can also be added to your
documentation or a technical appendix for a report. This plan can be in
a standalone text file, markdown file, or as comments in a syntax file
and should include, in <em>prose</em>, the steps you plan to take to
take your data from raw form to final analysis/clean form. Other people
may refer to this as a <a
href="https://www.teaguehenry.com/strings-not-factors/2021/1/24/data-management-for-researchers-three-terrifying-tales">“Chain
of Processing”</a>. This allows anyone to follow your data cleaning
process, even if they don’t understand your actual code (ex: R or Stata
code).<br />
<br></li>
</ul></li>
<li><p>Files used in data cleaning process (Ex:
<code>README_district_data-cleaning-process.txt</code>).</p>