-
Notifications
You must be signed in to change notification settings - Fork 2
/
imjadn-v1.0-cn01.html
4021 lines (3958 loc) · 201 KB
/
imjadn-v1.0-cn01.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 xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
<head>
<meta name="description" content="This document describes the use of Information models (IMs), explains how to construct IMs using JADN, and contrasts IMs with other modeling approaches.">
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Information Modeling with JADN Version 1.0</title>
<link rel="stylesheet" href="https://docs.oasis-open.org/templates/css/markdown-styles-v1.8.1-cn.css" />
</head>
<body>
<p><img src="https://docs.oasis-open.org/templates/OASISLogo-v3.0.png"
alt="OASIS Logo" /></p>
<h1 id="oasis-committee-note">OASIS Committee Note</h1>
<hr style="page-break-before: avoid" />
<h1big id="information-modeling-with-jadn-version-10">Information Modeling
with JADN Version 1.0</h1big>
<h2 id="committee-note-01">Committee Note 01</h2>
<h2 id="19-april-2023">19 April 2023</h2>
<p> </p>
<h4 id="this-stage">This stage:</h4>
<p><a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.md">https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.md</a>
(Authoritative)<br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.html">https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.html</a><br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.pdf">https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.pdf</a></p>
<h4 id="previous-stage-of-version-10">Previous stage of Version
1.0:</h4>
<p><a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.md">https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.md</a>
(Authoritative)<br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.html">https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.html</a><br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.pdf">https://docs.oasis-open.org/openc2/imjadn/v1.0/cnd01/imjadn-v1.0-cnd01.pdf</a></p>
<h4 id="latest-stage-of-version-10">Latest stage of Version 1.0:</h4>
<p><a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.md">https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.md</a>
(Authoritative)<br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html">https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html</a><br />
<a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.pdf">https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.pdf</a></p>
<h4 id="technical-committee">Technical Committee:</h4>
<p><a href="https://www.oasis-open.org/committees/openc2/">OASIS Open
Command and Control (OpenC2) TC</a></p>
<h4 id="chairs">Chairs:</h4>
<p>Duncan Sparrell (<a
href="mailto:duncan@sfractal.com">duncan@sfractal.com</a>), <a
href="http://www.sfractal.com/">sFractal Consulting LLC</a><br />
Michael Rosa (<a href="mailto:mjrosa@nsa.gov">mjrosa@nsa.gov</a>), <a
href="https://www.nsa.gov">National Security Agency</a></p>
<h4 id="editor">Editor:</h4>
<p>David Kemp (<a
href="mailto:d.kemp@cyber.nsa.gov">d.kemp@cyber.nsa.gov</a>), <a
href="https://www.nsa.gov/">National Security Agency</a></p>
<h4 id="related-work">Related work:</h4>
<p>This document is related to:</p>
<ul>
<li><em>JSON Abstract Data Notation Version 1.0</em>. Edited by David
Kemp. Latest stage: <a
href="https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html">https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html</a>.</li>
</ul>
<h4 id="abstract">Abstract:</h4>
<p>Information models (IMs) are used to define and generate physical
data models, validate information instances, and enable lossless
translation across data formats. JSON Abstract Data Notation (JADN) is a
UML-based information modeling language that defines data structure
independently of data format. This Committee Note describes the use of
IMs, explains how to construct IMs using JADN, and contrasts IMs with
other modeling approaches, such as Entity-Relationship models for
databases, and knowledge models / ontologies.</p>
<h4 id="status">Status:</h4>
<p>This is a Non-Standards Track Work Product. The patent provisions of
the OASIS IPR Policy do not apply.</p>
<p>This document was last revised or approved by the OASIS Open Command
and Control (OpenC2) TC on the above date. The level of approval is also
listed above. Check the "Latest stage" location noted above for possible
later revisions of this document. Any other numbered Versions and other
technical work produced by the Technical Committee (TC) are listed at <a
href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical">https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical</a>.</p>
<p>TC members should send comments on this document to the TC's email
list. Others should send comments to the TC's public comment list, after
subscribing to it by following the instructions at the "Send A Comment"
button on the TC's web page at <a
href="https://www.oasis-open.org/committees/openc2/">https://www.oasis-open.org/committees/openc2/</a>.</p>
<h4 id="citation-format">Citation format:</h4>
<p>When referencing this document the following citation format should
be used:</p>
<p><strong>[IM-JADN-v1.0]</strong></p>
<p><em>Information Modeling with JADN Version 1.0</em>. Edited by David
Kemp. 19 April 2023. OASIS Committee Note 01. <a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.html">https://docs.oasis-open.org/openc2/imjadn/v1.0/cn01/imjadn-v1.0-cn01.html</a>.
Latest stage: <a
href="https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html">https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html</a>.</p>
<h4 id="notices">Notices</h4>
<p>Copyright © OASIS Open 2023. All Rights Reserved.</p>
<p>Distributed under the terms of the OASIS <a
href="https://www.oasis-open.org/policies-guidelines/ipr/">IPR
Policy</a>.</p>
<p>The name "OASIS" is a trademark of <a
href="https://www.oasis-open.org/">OASIS</a>, the owner and developer of
this specification, and should be used only to refer to the organization
and its official outputs.</p>
<p>For complete copyright information please see the full Notices
section in <a href="#appendix-f-notices">Appendix F</a>.</p>
<hr />
<h1 id="table-of-contents">Table of Contents</h1>
<ul type="none">
<li><a href="#1-introduction">1 Introduction</a>
<ul type="none">
<li><a href="#11-background-motivation-for-jadn">1.1 Background:
Motivation for JADN</a></li>
<li><a href="#111-openc2-and-jadn">1.1.1 OpenC2 and JADN</a></li>
<li><a href="#112-the-information-modeling-gap">1.1.2 The Information
Modeling Gap</a></li>
<li><a href="#12-purpose">1.2 Purpose</a></li>
<li><a href="#13-terminology">1.3 Terminology</a></li>
</ul></li>
<li><a href="#2-information-modeling-overview">2 Information Modeling
Overview</a>
<ul type="none">
<li><a href="#21-defining-information">2.1 Defining
"Information"</a></li>
<li><a href="#22-information-models-and-data-models">2.2 Information
Models And Data Models</a></li>
<li><a href="#23-benefits-of-information-models">2.3 Benefits of
Information Models</a></li>
<li><a href="#24-serialization">2.4 Serialization</a></li>
<li><a href="#25-information-modeling-languages">2.5 Information
Modeling Languages</a></li>
<li><a href="#26-information-modeling-tools">2.6 Information Modeling
Tools</a></li>
<li><a href="#27-applying-an-information-model">2.7 Applying an
Information Model</a></li>
</ul></li>
<li><a href="#3-creating-information-models-with-jadn">3 Creating
Information Models with JADN</a>
<ul type="none">
<li><a href="#31-jadn-overview">3.1 JADN Overview</a>
<ul type="none">
<li><a href="#311-type-definitions">3.1.1 Type Definitions</a></li>
<li><a href="#312-typeoptions">3.1.2 TypeOptions</a></li>
<li><a href="#313-item-or-field-definitions">3.1.3 Item Or Field
Definitions</a></li>
<li><a href="#314-field-options">3.1.4 Field Options</a></li>
<li><a href="#315-jadn-representations">3.1.5 JADN Representations</a>
<ul type="none">
<li><a href="#3151-native-json-representation">3.1.5.1 Native JSON
Representation</a></li>
<li><a href="#3152-alternative-jadn-representations">3.1.5.2 Alternative
JADN Representations</a>
<ul type="none">
<li><a href="#31521--array-field-names-in-jidl">3.1.5.2.1 Array "Field
Names" in JIDL</a></li>
</ul></li>
<li><a href="#3153-multiple-representations-example">3.1.5.3 Multiple
Representations Example</a></li>
</ul></li>
<li><a href="#316-anonymous-type-definitions">3.1.6 "Anonymous" Type
Definitions</a></li>
<li><a href="#317-base-type-examples">3.1.7 Base Type Examples</a>
<ul type="none">
<li><a href="#3171-binary">3.1.7.1 Binary</a></li>
<li><a href="#3172-boolean">3.1.7.2 Boolean</a></li>
<li><a href="#3173-integer">3.1.7.3 Integer</a></li>
<li><a href="#3174-number">3.1.7.4 Number</a></li>
<li><a href="#3175-string">3.1.7.5 String</a></li>
<li><a href="#3176-enumerated">3.1.7.6 Enumerated</a></li>
<li><a href="#3177-choice">3.1.7.7 Choice</a></li>
<li><a href="#3178-array">3.1.7.8 Array</a></li>
<li><a href="#3179-arrayofvtype">3.1.7.9
ArrayOf(<em>vtype</em>)</a></li>
<li><a href="#31710-map">3.1.7.10 Map</a></li>
<li><a href="#31711-mapofktypevtype">3.1.7.11
MapOf(<em>ktype</em>,<em>vtype</em>)</a></li>
<li><a href="#31712-record">3.1.7.12 Record</a></li>
</ul></li>
</ul></li>
<li><a href="#32-information-modeling-process">3.2 Information Modeling
Process</a>
<ul type="none">
<li><a href="#321-y-tina-lee-modeling-process">3.2.1 Y. Tina Lee
Modeling Process</a></li>
<li><a href="#322-frederiks--van-der-weide-modeling-process">3.2.2
Frederiks / van der Weide Modeling Process</a></li>
</ul></li>
<li><a href="#33-information-modeling-example">3.3 Information Modeling
Example</a>
<ul type="none">
<li><a href="#331-example-1-a-digital-music-library">3.3.1 Example 1: A
Digital Music Library</a></li>
</ul></li>
</ul></li>
<li><a href="#4-advanced-techniques">4 Advanced Techniques</a>
<ul type="none">
<li><a href="#41-packages-and-namespaces">4.1 Packages and
Namespaces</a>
<ul type="none">
<li><a href="#411-packages">4.1.1 Packages</a></li>
<li><a href="#412-namespaces">4.1.2 Namespaces</a></li>
</ul></li>
<li><a href="#42-reference-relationships-keys-and-links">4.2 Reference
Relationships: Keys and Links</a></li>
</ul></li>
<li><a href="#appendix-a-informative-references">Appendix A. Informative
References</a></li>
<li><a href="#appendix-b-acknowledgments">Appendix B.
Acknowledgments</a></li>
<li><a href="#appendix-c-revision-history">Appendix C. Revision
History</a></li>
<li><a href="#appendix-d-frequently-asked-questions-faq">Appendix D.
Frequently Asked Questions (FAQ)</a>
<ul type="none">
<li><a href="#d1-jadn-vs-uml-primitive-data-types">D.1 JADN vs. UML
Primitive Data Types</a></li>
<li><a href="#d2-why-jadn-and-not-rdf">D.2 Why JADN and not
RDF?</a></li>
<li><a href="#d3-why-jadn-and-not-owl">D.3 Why JADN and not
OWL?</a></li>
</ul></li>
<li><a href="#appendix-e-example-information-model-source">Appendix E.
Example Information Model Source</a>
<ul type="none">
<li><a href="#e1-music-library">E.1 Music Library</a></li>
</ul></li>
<li><a href="#appendix-f-notices">Appendix F. Notices</a></li>
</ul>
<p><strong>List of Figures</strong></p>
<ul type="none">
<li><a href="#figure-1-1----range-of-model-types">Figure 1-1 -- Range of
Model Types</a></li>
<li><a href="#figure-2-1----serialization--deserialization">Figure 2-1
-- Serialization / Deserialization</a></li>
<li><a href="#figure-2-2----parsing-and-serializing-with-an-im">Figure
2-2 -- Parsing and Serializing With An IM</a></li>
<li><a href="#figure-3-1----jadn-concepts">Figure 3-1 -- JADN
Concepts</a></li>
<li><a href="#figure-3-2----jadn-type-definition-structure">Figure 3-2
-- JADN Type Definition Structure</a></li>
<li><a
href="#figure-3-3----jadn-for-primitive-arrayof-mapof-types">Figure 3-3
-- JADN for Primitive, ArrayOf, MapOf Types</a></li>
<li><a href="#figure-3-4----jadn-for-enumerated-types">Figure 3-4 --
JADN for Enumerated Types</a></li>
<li><a href="#figure-3-5----jadn-for-types-with-fields">Figure 3-5 --
JADN for Types with Fields</a></li>
<li><a href="#figure-3-6----simple-university-example-erd">Figure 3-6 --
Simple University Example ERD</a></li>
<li><a
href="#figure-3-7----simple-university-example-jadn-json-format">Figure
3-7 -- Simple University Example JADN (JSON format)</a></li>
<li><a
href="#figure-3-8----simple-university-example-jadn-jidl-format">Figure
3-8 -- Simple University Example JADN (JIDL format)</a></li>
<li><a
href="#figure-3-9----simple-university-example-jadn-table-format">Figure
3-9 -- Simple University Example JADN (table format)</a></li>
<li><a
href="#figure-3-10----simple-university-example-erd-source-code-graphviz">Figure
3-10 -- Simple University Example ERD Source Code (GraphViz)</a></li>
<li><a href="#figure-3-11----music-library-example-erd">Figure 3-11 --
Music Library Example ERD</a></li>
<li><a
href="#figure-4-1----contains-and-references-relationships">Figure 4-1
-- Contains and References Relationships</a></li>
</ul>
<p><strong>List of Tables</strong></p>
<ul type="none">
<li><a href="#table-3-1----compound-type-decision-tree">Table 3-1 --
Compound Type Decision Tree</a></li>
<li><a href="#table-3-2----multiplicity-types">Table 3-2 -- Multiplicity
Types</a></li>
<li><a href="#table-3-3----jadn-type-options">Table 3-3 -- JADN Type
Options</a></li>
<li><a href="#table-3-4----type-option-applicability">Table 3-4 -- Type
Option Applicability</a></li>
<li><a href="#table-3-5----jadn-field-options">Table 3-5 -- JADN Field
Options</a></li>
<li><a href="#table-3-6----binary-type-format-options">Table 3-6 --
Binary Type Format Options</a></li>
<li><a href="#table-3-7----integer-type-format-options">Table 3-7 --
Integer Type Format Options</a></li>
<li><a href="#table-3-8----number-type-format-options">Table 3-8 --
Number Type Format Options</a></li>
<li><a href="#table-3-9----array-type-format-options">Table 3-9 -- Array
Type Format Options</a></li>
<li><a href="#table-d-1----uml-and-jadn-basic-type-equivalence">Table
D-1 -- UML and JADN Basic Type Equivalence</a></li>
</ul>
<hr />
<!-- Insert a "line rule" (three or more hyphens alone on a new line, following a blank line) before each major section. This is used to generate a page break in the PDF format. -->
<h1 id="1-introduction">1 Introduction</h1>
<p>An Information Model (IM) defines the essential content of messages
used in computing, independently of how those messages are represented
(i.e., <a href="#24-serialization">serialized</a>) for communication or
storage. This Committee Note (CN) describes the nature of an IM, and the
application of the <em>JSON Abstract Data Notation</em> [<a
href="#jadn-v10">JADN</a>] information modeling language in the creation
and use of IMs.</p>
<h2 id="11-background-motivation-for-jadn">1.1 Background: Motivation
for JADN</h2>
<p>This section provides the background for the creation of JADN as an
information modeling language for a spectrum of applications.</p>
<h3 id="111-openc2-and-jadn">1.1.1 OpenC2 and JADN</h3>
<p>The <em>OpenC2 Architecture Specification</em> [<a
href="#openc2-arch-v10">OpenC2-Arch-v1.0</a>] abstract defines the
objective of OpenC2:</p>
<blockquote>
<p><em>Open Command and Control (OpenC2) is a concise and extensible
language to enable machine-to-machine communications for purposes of
command and control of cyber defense components, subsystems and/or
systems in a manner that is agnostic of the underlying products,
technologies, transport mechanisms or other aspects of the
implementation.</em></p>
</blockquote>
<p>The OASIS <a
href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2">OpenC2
Technical Committee (TC)</a> recognized the need to define the OpenC2
Language [<a href="#openc2-lang-v10">OpenC2-Lang-v1.0</a>] in an
implementation-independent manner in order to achieve the project's
goals to be "agnostic of the underlying products, technologies,
transport mechanisms or other aspects of the implementation". In
response, the TC created an information modeling language, <em>JSON
Abstract Data Notation</em> [<a href="#jadn-v10">JADN</a>], to support
the information modeling needed to define OpenC2 in that manner.</p>
<p>It is important to recognize that while JADN was created to
facilitate the development of OpenC2, it is an independent
specification, and can be used for any information modeling
application.</p>
<h3 id="112-the-information-modeling-gap">1.1.2 The Information Modeling
Gap</h3>
<p>The IETF, in the <em>Report from the Internet of Things (IoT)
Semantic Interoperability (IOTSI) Workshop 2016</em> [<a
href="https://www.rfc-editor.org/info/rfc8477">RFC 8477</a>], attributed
challenges in achieving interoperability to a lack of information
modeling:</p>
<blockquote>
<p><em>One common problem is the lack of an encoding-independent
standardization of the information, the so-called information model.
Another problem is the strong relationship between data formats and the
underlying communication architecture</em></p>
</blockquote>
<p>A key term in the above is "encoding-independent". An IM defines the
essential content of messages used in computing, independently of how
those messages are represented (i.e., serialized) for communication or
storage. IMs are used to define and generate physical data models,
validate information instances, and enable lossless translation across
data formats. While JADN was created by the OpenC2 TC, it is entirely
general purpose in its design and can be used to create IMs for nearly
any purpose. Examples of other possible JADN applications include
defining:</p>
<ul>
<li>Complex information structures, such as Software Bills of Materials
(SBOMs) [<a href="#ntia-sbom">NTIA-SBOM</a>]; examples would be the SPDX
and CycloneDX SBOM formats</li>
<li>Formal definition of structured information exchanges, such as are
described by <a
href="https://github.com/niemopen/oasis-open-project#readme">NIEM</a></li>
</ul>
<p>[<a href="https://www.rfc-editor.org/info/rfc8477">RFC 8477</a>]
defines information models and data models to clarify the differences
(emphasis added):</p>
<ul>
<li><p><strong>Information Model</strong> -- An information model
defines an environment <em>at the highest level of abstraction and
expresses the desired functionality</em>. Information models can be
defined informally (e.g., in prose) or more formally (e.g., Unified
Modeling Language (UML), Entity- Relationship Diagrams, etc.).
Implementation details are hidden.</p></li>
<li><p><strong>Data Model</strong> -- A data model defines concrete data
representations <em>at a lower level of abstraction, including
implementation- and protocol-specific details</em>. Some examples are
SNMP Management Information Base (MIB) modules, World Wide Web
Consortium (W3C) Thing Description (TD) Things, YANG modules,
Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity
Foundation (OCF) Schemas, and so on.</p></li>
</ul>
<p>Expanding somewhat on the RFC 8477 hierarchy, a JADN information
model is positioned within <em>three</em> abstraction levels, the
highest being:</p>
<ul>
<li><strong>Logical Model</strong> -- A logical model defines the
semantics (knowledge/meaning) assigned to things being modeled. Logical
models are defined using languages such as the W3C Web Ontology Language
[<a href="#owl-primer">OWL</a>].</li>
</ul>
<p>The layering of these models is illustrated in Figure 1-1.</p>
<h6 id="figure-1-1----range-of-model-types">Figure 1-1 -- Range of Model
Types</h6>
<p><img src="images/model-types.drawio.png"
alt="Figure 1-1 -- Range of Model Types" /></p>
<p>JADN is based on Information Theory [<a
href="#info-theory">Info-Theory</a>], which provides a concrete way of
quantifying information that is explicitly independent of both semantic
meaning and data representation. A JADN IM links model-defined semantic
types with JADN-defined core information types, providing an unambiguous
bridge between semantics and data. This supports implementation
flexibility while maintaining interoperable information exchange across
implementations.</p>
<h2 id="12-purpose">1.2 Purpose</h2>
<p>As an IM language, JADN is a syntax-independent, or abstract, schema
language. Abstract schema languages separate structure definitions from
encoding rules. JADN is oriented to work well with common Internet data
formats, such as</p>
<ul>
<li>JSON (Javascript Object Notation)</li>
<li>XML (eXtensible Markup Language)</li>
<li>CBOR (Concise Binary Object Representation)</li>
</ul>
<p>JADN is based rigorously on information theory, and an IM composed in
JADN formally defines equivalence of information content between data in
different formats.</p>
<p>This CN discusses:</p>
<ol type="1">
<li>Key concepts: information, data, serialization.</li>
<li>What is information modeling?</li>
<li>The value of an information model.</li>
<li>The distinction between an IM and other modeling approaches.</li>
<li>The creation and use of an IM using JADN and associated automated
tools.</li>
</ol>
<h2 id="13-terminology">1.3 Terminology</h2>
<p>This CN uses the definitions contained in the [<a
href="#jadn-v10">JADN Specification</a>], section 1.2.1. The following
additional terms are defined for this document:</p>
<ul>
<li><p><strong>Directed Acyclic Graph:</strong> A directed acyclic graph
(DAG) is a directed graph with no directed cycles. That is, it consists
of vertices and edges (also called arcs), with each edge directed from
one vertex to another, such that following those directions will never
form a closed loop. A directed graph is a DAG if and only if it can be
topologically ordered, by arranging the vertices as a linear ordering
that is consistent with all edge directions<br>(Wikipedia, <a
href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">https://en.wikipedia.org/wiki/Directed_acyclic_graph</a>)</p></li>
<li><p><strong>Entity Relationship Model:</strong> An
entity–relationship model (or ER model) describes interrelated things of
interest in a specific domain of knowledge. A basic ER model is composed
of entity types (which classify the things of interest) and specifies
relationships that can exist between entities (instances of those entity
types).<br>(Wikipedia, <a
href="https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model">https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model</a>)</p></li>
<li><p><strong>Schema:</strong> <em>(markup languages)</em> A formal
description of data, data types, and data file structures, such as XML
schemas for XML files.<br>(Wiktionary, <a
href="https://en.wiktionary.org/wiki/schema#Noun">https://en.wiktionary.org/wiki/schema#Noun</a>,
definition #3)</p></li>
<li><p><strong>Ontology:</strong> (information science) A
representation, formal naming, and definition of the categories,
properties, and relations between the concepts, data, and entities that
substantiate one, many, or all domains of discourse. More simply, an
ontology is a way of showing the properties of a subject area and how
they are related, by defining a set of concepts and categories that
represent the subject.<br> (Wikipedia, <a
href="https://en.wikipedia.org/wiki/Ontology_(computer_science)">https://en.wikipedia.org/wiki/Ontology_(computer_science)</a>)</p></li>
</ul>
<hr />
<h1 id="2-information-modeling-overview">2 Information Modeling
Overview</h1>
<p>This section discusses the nature and benefits of IMs, the role of
serialization, types of available modeling languages, and tools that can
be used in information modeling.</p>
<h2 id="21-defining-information">2.1 Defining "Information"</h2>
<p>A basic problem with discussing information models is that the terms
"information" and "data" are used widely but defined imprecisely. The
use of these terms across technical literature has considerable
variation and overlap. As described in <em>What is Shannon
information?</em> [<a href="#lombardi">Lombardi</a>], a precise
definition of "information" is a relatively recent development:</p>
<blockquote>
<p>Nevertheless, it is traditionally agreed that the seminal work for
the mathematical view of information is the paper where Claude Shannon
(1948) introduces a precise formalism designed to solve certain specific
technological problems in communication engineering. ... Nowadays,
Shannon’s theory is a basic ingredient of the communication engineers
training.</p>
</blockquote>
<p>Shannon's original article was later published as a book and gave
rise to the field of Information Theory [<a
href="#shannon">Shannon</a>].</p>
<p>A small example may help clarify the concept of information. The
information content of an instance can be no greater than the smallest
data instance for which lossless round-trip conversion is possible. For
example, an IPv4 address represented in dotted quad format is 17 bytes
of JSON string data ("192.168.101.213"), but can be converted to 4 byte
RFC 791 format and back without loss. The information content of an IPv4
address can therefore be no greater than 4 bytes (32 bits), and an
information model would define the IPv4 address type as a byte sequence
of length 4.</p>
<p>For the purpose of understanding information modeling, it is helpful
to think in terms of different levels of representation:</p>
<ul>
<li>External</li>
<li>Internal</li>
<li>Conceptual</li>
</ul>
<p>These levels correspond, respectively, to the Data, Information, and
Logical models illustrated above in <a
href="#figure-1-1----range-of-model-types">Figure 1-1</a>.</p>
<p>The external representation requires a data model to describe how
information is transmitted or stored; such a data model provides
specific formats and syntax (e.g., defining serialization rules) that
permit moving the data out of the system where it is being processed.
The internal representation depends on an information model, which uses
abstract terminology to focus on what the information represents (e.g.,
a name, an address). As described in [<a href="#ytlee">YTLee</a>]'s 2008
paper on information modeling:</p>
<blockquote>
<p>The conceptual view is a single, integrated definition of the data
within an enterprise that is unbiased toward any single application of
data and independent of how the data is physically stored or accessed.
It provides a consistent definition of the meanings and
interrelationship of the data in order to share, integrate, and manage
the data.</p>
</blockquote>
<p>Note that while this description uses the term "data", the more
important terms are "unbiased", "independent", "consistent", and
"meanings and interrelationship".</p>
<p>A common language for defining conceptual models is OWL (Web Ontology
Language, see <a href="#owl-primer">OWL-Primer</a>). An abstract
information model, such as can be created with JADN, bridges between the
conceptual model (described using OWL or similar languages), and and the
external (or concrete) representation in a selected data format. JADN
directly models the Shannon information for creating serialized data in
one or more desired formats. By creating the information model to bridge
concept to representation, the concept of <strong>"information
equivalence"</strong> is applied: the same information model can be used
to generate both self-describing (verbose) data and concise data for
production environments.</p>
<h2 id="22-information-models-and-data-models">2.2 Information Models
And Data Models</h2>
<p>As described in the introduction, IMs are a means to understand and
document the essential information content relevant to a system,
application, or protocol exchange without regard to how that information
is represented in actual implementations. Having a clear view of the
information required provides clarity regarding the goals that the
eventual implementation must satisfy.</p>
<p>[<a href="#rfc3444">RFC 3444</a>] describes the purpose of an IM
as:</p>
<blockquote>
<p>"to model managed objects at a conceptual level, independent of any
specific implementations or protocols used to transport the data. ...
Another important characteristic of an IM is that it defines
relationships between managed objects."</p>
</blockquote>
<p>[<a href="#ytlee">YTLee</a>] describes an IM as follows:</p>
<blockquote>
<p>"An information model is a representation of concepts, relationships,
constraints, rules, and operations to specify data semantics for a
chosen domain of discourse."</p>
</blockquote>
<p>[<a href="#rfc3444">RFC3444</a>] contrasts IMs with data models
(DMs):</p>
<blockquote>
<p>"Compared to IMs, DMs define managed objects at a lower level of
abstraction. They include implementation- and protocol-specific details,
e.g., rules that explain how to map managed objects onto lower-level
protocol constructs."</p>
</blockquote>
<p>and states DMs are "intended for implementors and include
protocol-specific constructs".</p>
<p>The following key principles apply to IMs:</p>
<ul>
<li><p>An information model classifies the validity of serialized data
with zero false positives and zero false negatives. That is, an
information model is the <em>authoritative definition</em> of essential
content, and any serialized data is unambiguously one of: a) consistent
with, b) inconsistent with, or c) insignificant with respect to, the
model.</p></li>
<li><p>Information instances are values that can be compared for
equality. An application compares instances in accordance with the UML
properties defined by their datatype. Two instances are equal if they
have the same datatype and the same value.</p></li>
<li><p>If an instance can be losslessly converted among multiple
serializations, then its information content is no greater than the
smallest of those serializations.</p></li>
</ul>
<h2 id="23-benefits-of-information-models">2.3 Benefits of Information
Models</h2>
<p>A key point in all the IM definitions and descriptions in the
previous section is the ability for the model to represent information
with a focus on its <em>meaning</em>, and without concern for how that
information will be represented. Focusing on meaning encourages
interoperability between applications by capturing agreement about what
the information conveys and how it can be used, deferring decisions on
storage and transmission matters until a clear understanding of purpose
has been reached. Referring back to the example of the IPv4 address,
regardless of representation the address identifies the label applied to
a network interface within an available address space of 2^32.</p>
<p>[<a href="#ytlee">YTLee</a>] identifies the key benefit of an IM:</p>
<blockquote>
<p>"The advantage of using an information model is that it can provide
sharable, stable, and organized structure of information requirements
for the domain context."</p>
</blockquote>
<p>and describes a "quality" IM as being:</p>
<ul>
<li>complete,</li>
<li>sharable,</li>
<li>stable,</li>
<li>extensible,</li>
<li>well-structured,</li>
<li>precise, and</li>
<li>unambiguous.</li>
</ul>
<p>To sum up, in <a href="#dthaler">DThaler's</a> paper on <em>IoT
Bridge Taxonomy</em>, which addresses the challenges created when "many
organizations develop and implement different schemas for the same kind
of things", the concluding Recommendations section includes the
following:</p>
<blockquote>
<p>To ... increase semantic interoperability, it is desirable that
different data models for the same type of thing (e.g., light bulbs) are
as similar as possible for basic functionality. In an ideal world, data
models used by different protocols and organizations would express
exactly the same information in ways that are algorithmically
translatable by a dynamic schema bridge with no domain-specific
knowledge. Sharing data models more widely, and having agreements in
principle of at least using the same abstract information model, would
be very beneficial.</p>
</blockquote>
<p>The notion of "express[ing] exactly the same information in ways that
are algorithmically translatable" is a fundamental purpose of
information modeling, and aligns with the JADN concept of
<em>information equivalence</em>.</p>
<h2 id="24-serialization">2.4 Serialization</h2>
<p>Information exists in the minds of users (producers and consumers),
in the state of applications running on systems, and in the data
exchanged among applications. Serialization converts application
information into byte sequences (a.k.a. protocol data units, messages,
payloads, information exchange packages) that can be validated,
communicated and stored. De-serialization parses payloads back into
application state. Serialization is not a goal in and of itself, it is
the mechanism by which applications exchange information in order to
make it available to users.</p>
<h6 id="figure-2-1----serialization--deserialization">Figure 2-1 --
Serialization / Deserialization</h6>
<p><img src="images/model-and-serialization.png"
alt="Figure 2-1 -- Serialization / Deserialization" /></p>
<p>Serialization and deserialization are intimately connected to the
chosen format: the same data can be serialized in JSON, CBOR, and XML,
and while the serialized data will look very different, the received
information that is recovered by deserialization should match the
transmitted information. The [<a href="#jadn-v10">JADN
Specification</a>] include serialization rules for four different
formats:</p>
<ul>
<li>Verbose JSON</li>
<li>Compact JSON</li>
<li>Concise JSON</li>
<li>CBOR</li>
</ul>
<p>The specification also describes what is needed to connect JADN and
IMs defined in JADN to other serialization formats:</p>
<ul>
<li>Specify an unambiguous serialized representation for each JADN
type</li>
<li>Specify how each option applicable to a type affects serialized
values</li>
<li>Specify any validation requirements defined for that format.</li>
</ul>
<p>Regardless of format, serialization should be:</p>
<ol type="1">
<li><strong>lossless</strong>, so that information is not modified in
transit and all applications have the identical information</li>
<li><strong>transparent</strong>, so that information is unaffected by
whether or how it has been serialized; users should not know or
care.</li>
</ol>
<p>As noted above, serialization is an important aspect of
implementation, but it is a means to an end. The user cares about the
information the serialized data represents, not the format by which it
is moved from system to system. An Automated Teller Machine customer
cares about their bank balance, and an airline customer cares that their
tickets are for the proper flights. How the information system handles
the bits to make that happen is of no concern to the customer.</p>
<p>Shannon's information theory defines the relationship between
information and serialization (coding). Mathematicians characterize
conditions applied to a mechanism as <em>necessary</em> and/or
<em>sufficient</em>: a serialization that omits necessary data loses
information, one that uses more data than sufficient conveys no extra
information, and potentially wastes storage or communications bandwidth.
However, particular requirements (e.g., human readability) may indicate
that a serialization that uses more data than sufficient is appropriate
for particular situations.</p>
<h2 id="25-information-modeling-languages">2.5 Information Modeling
Languages</h2>
<p>[<a href="#ytlee">YTLee</a>] describes an IM language as follows:</p>
<blockquote>
<p>"An information modeling language is a formal syntax that allows
users to capture data semantics and constraints."</p>
</blockquote>
<p>and defines their importance:</p>
<blockquote>
<p>"Formal information modeling languages that describe information
requirements unambiguously is an enabling technology that facilitates
the development of a large scale, networked, computer environment that
behaves consistently and correctly."</p>
</blockquote>
<p><em>Report from IoT Semantic Interoperability Workshop 2016</em> [<a
href="#rfc8477">RFC 8477</a>] describes a lack of consistency across
Standards Developing Organizations (SDOs) in defining application layer
data, attributing it to the lack of an encoding-independent
standardization of the information represented by that data. The JADN
information modeling language is intended to address that gap. Abstract
Syntax Notation One [<a href="#asn1">ASN.1</a>] is another example of an
abstract schema language.</p>
<p>JADN is a syntax-independent schema language, based on Unified
Modeling Language (UML) datatypes. JADN is designed to work with common
Internet data formats (JSON, XML, CBOR), providing a schema to support
them. JADN is also graph-oriented to align with the web and database
design practices, with options to identify primary and foreign keys,
including web URLs..</p>
<p>JADN's native format is structured JSON, and a broad variety of tools
exist for creating and manipulating information in JSON format.</p>
<ul>
<li>a JADN schema is structured data that can be generated and
transformed programmatically</li>
<li>JADN schemas employ a simple, regular structure (every type
definition has the same five fields)</li>
</ul>
<p>ASN.1 is a formal notation used for describing data transmitted by
telecommunications protocols, regardless of language implementation and
physical representation of these data, whatever the application, whether
complex or very simple. The notation provides a certain number of
pre-defined basic types, and makes it possible to define constructed
types. Subtyping constraints can be also applied on any ASN.1 type in
order to restrict its set of values. Data described in ASN.1 is
serialized and deserialized based on set of encoding rules, which are
defined for a broad variety of formats including the Basic Encoding
Rules (BER) and similar, which are closely associated with ASN.1, as
well as less closely tied standards such as XML and JSON.</p>
<p>Other languages have been used for information modeling, although
that is not their primary purposes. Some examples are Unified Modeling
Language [<a href="#uml">UML</a>], and Integration DEFinition for
information modeling [<a href="#idef1x">IDEF1X</a>].</p>
<h2 id="26-information-modeling-tools">2.6 Information Modeling
Tools</h2>
<p>The value of an IM language multiplies when automated tooling is
available to support creation, maintenance, and use of models created in
that language. The need for tools is discussed in [<a
href="#rfc8477">RFC 8477</a>], citing particularly the need for code
generation and debugging tools. A tool set to support an IM language
should provide</p>
<ul>
<li>Model creation capabilities</li>
<li>Model validation capabilities</li>
<li>Translation among alternative representations of the IM (e.g.,
textual, graphical)</li>
<li>Generation of language-specific schemas from an IM</li>
<li>Model translation to language- or protocol-specific serialization /
deserialization capabilities</li>
</ul>
<h2 id="27-applying-an-information-model">2.7 Applying an Information
Model</h2>
<p>A primary application of an IM is in the translation of data into and
out of in-memory representation and serialized formats for storage and
transmission. The IM defines the types, organization, and validation
requirements for the information manipulated by an application or
protocol. Within an application the IM is instantiated through the data
structures and types supported by the chosen programming language. The
IM also guides the creation of routines to parse and validate data being
input from storage or through communications, and to serialize data
being output to storage or transmission. Deriving the processing
capabilities from the IM ensures consistency as the data is manipulated.
Figure 2-2 illustrates the concept of applying an IM to manage the
associated data.</p>
<h6 id="figure-2-2----parsing-and-serializing-with-an-im">Figure 2-2 --
Parsing and Serializing With An IM</h6>
<p><img src="images/parse-serialize.drawio.png"
alt="Parsing and Serializing With An IM" /></p>
<p>The internal representation, illustrated in Figure 2-1 as a tree, is
guided by rules associated with applying the IM:</p>
<ul>
<li>the internal representation conforms to the IM</li>
<li>each node in the internal representation has an abstract core type
from the IM</li>
<li>each core type has associated serialization rules for each external
representation format</li>
</ul>
<p>The JADN Specification [<a href="#jadn-v10">JADN-v1.0</a>] defines 12
core types, which are described in <a
href="#317-base-type-examples">Section 3.1.7</a> of this CN. The JADN
Specification also defines serialization rules for JSON (with three
levels of verbosity) and CBOR [<a href="#rfc7049">RFC7409</a>].
Supporting a new data format ("external representation") requires
defining serialization rules to translate each core type to that data
format.</p>
<p>As an example, consider an information element defined as a boolean
type, which is the simplest core type. The essential nature of a boolean
is that it is limited to only two values, usually identified as "true"
and "false". However, the <em>data</em> representing a Boolean value is
determined by serialization rules, and could be any of "false" and
"true", 0 and 1, "n" and "y", etc. In a programming language, many
variable types and values may evaluate as "true":</p>
<ul>
<li>Non-zero integers</li>
<li>Non-empty strings</li>
<li>Non-empty arrays</li>
</ul>
<p>An abstract representation of an IM does not capture data types and
values for a Boolean node, e.g. integer 0 or 37 or string "yes". It has
only the characteristics of the node type: false or true. A JSON
representation can use a Boolean type with values 'false' and 'true',
but for efficient serialization might also use the JSON number type with
values 0 and 1.</p>
<hr />
<h1 id="3-creating-information-models-with-jadn">3 Creating Information
Models with JADN</h1>
<p>This section provides a brief overview of JADN, and describes the use
of JADN in information modeling.</p>
<h2 id="31-jadn-overview">3.1 JADN Overview</h2>
<p>Figure 3-1 provides a high-level view of the JADN concepts that will
be described in this section. JADN provides simple and compound data
types that can be refined using type and field options (field options
only apply within compound types). JADN can also be represented in
multiple formats, both textual and graphical, and automated tooling can
transform a JADN model between the different representations without
loss of information. The Native JADN representation as JSON data is
authoritative, but each representation has advantages.</p>
<h6 id="figure-3-1----jadn-concepts">Figure 3-1 -- JADN Concepts</h6>
<p><img src="images/JADN-Concepts.drawio.png"
alt="Figure 3-1 -- JADN Concepts" /></p>
<p>The JADN information modeling language was developed against specific
objectives:</p>
<ol type="1">
<li>Core types represent application-relevant "information", not
"data"</li>
<li>Single specification unambiguously defines multiple data
formats</li>
<li>Specification uses named type definitions equivalent to property
tables</li>
<li>Specification is data that can be serialized</li>
<li>Specification has a fixed structure designed for extensibility</li>
</ol>
<p>As described in the JADN Specification [<a
href="#jadn-v10">JADN-v1.0</a>] introduction:</p>
<blockquote>
<p>JADN is a formal description technique that combines type constraints
from the Unified Modeling Language (UML) with data abstraction based on
information theory and structural organization using results from graph
theory.</p>
</blockquote>
<blockquote>
<p><strong>EDITOR'S NOTE:</strong> consider whether the following adds
clarity or confusion; it might need to be re-written to guide the reader
through the concepts a bit more.</p>
</blockquote>
<p>From UML JADN takes the concept of modeling information/data using
Simple Classifiers (see [<a href="#uml">UML</a>], 10.2 Datatypes) as
opposed to the common practice of using Structured Classifiers ([<a
href="#uml">UML</a>], 11.4 Classes), which do not define data in a
unique way that can be validated and signed. The JADN use of the UML
primitive types defined in [<a href="#uml">UML</a>], Table 21.1, can be
found in <a href="#d1-jadn-vs-uml-primitive-data-types">Appendix
D.1</a>.</p>
<p>The [<a href="#jadn-v10">JADN Specification</a>] defines twelve base
types:</p>
<table>
<thead>
<tr class="header">
<th style="text-align: center;"><strong>Primitive</strong></th>
<th style="text-align: center;"><strong>Compound</strong></th>
<th style="text-align: center;"><strong>Selection /<br>
Union</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">Binary</td>
<td style="text-align: center;">Array</td>
<td style="text-align: center;">Enumerated</td>
</tr>
<tr class="even">
<td style="text-align: center;">Boolean</td>
<td style="text-align: center;">ArrayOf</td>
<td style="text-align: center;">Choice</td>
</tr>
<tr class="odd">
<td style="text-align: center;">Integer</td>
<td style="text-align: center;">Map</td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: center;">Number</td>
<td style="text-align: center;">MapOf</td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: center;">String</td>
<td style="text-align: center;">Record</td>
<td style="text-align: center;"></td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>NOTE:</strong> The JADN v1.0 Committee Specification [<a
href="#jadn-v10">JADN</a>] uses the term "structured" rather than
"compound" when referring to Array, ArrayOf, Map, MapOf, and Record
types. An update is planned to change the specification to use
"compound" in order to avoid any potential confusion with UML's use of
"structured".</p>
</blockquote>
<p>Each of the compound types is a <em>container</em>, a named group of
related items such as the latitude and longitude of a geographic
coordinate, or the set of properties of an object. In addition to its
individual items, every container has <em>multiplicity</em> attributes,
including limits on the number of items, whether the items have a
sequential ordering, and whether duplicate items are allowed.</p>
<p>The JADN compound type and its options are chosen for an IM based on
the information characteristics to be modeled:</p>
<ul>
<li>Array and ArrayOf contain a group of values.</li>
<li>Map, MapOf and Record contain a group of keys and corresponding
values (a mapping)</li>
<li>All items in ArrayOf and MapOf groups have the same value (and key)
type</li>
<li>Each item in Array, Map, and Record groups has an individual value
(and key) type</li>
</ul>
<p>and the decision tree for which compound type to use is shown in
Table 3-1:</p>
<h6 id="table-3-1----compound-type-decision-tree">Table 3-1 -- Compound
Type Decision Tree</h6>
<table>
<thead>
<tr class="header">
<th style="text-align: center;">Value / Mapping</th>
<th style="text-align: center;">Same / Individual</th>
<th style="text-align: center;">JADN Type</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">Value</td>
<td style="text-align: center;">Same</td>
<td style="text-align: center;">ArrayOf(ValueType)</td>
</tr>
<tr class="even">
<td style="text-align: center;">Value</td>
<td style="text-align: center;">Individual</td>
<td style="text-align: center;">Array</td>
</tr>
<tr class="odd">
<td style="text-align: center;">Key:Value</td>
<td style="text-align: center;">Same</td>
<td style="text-align: center;">MapOf(KeyType, ValueType)</td>
</tr>
<tr class="even">
<td style="text-align: center;">Key:Value</td>
<td style="text-align: center;">Individual</td>
<td style="text-align: center;">Map or Record</td>
</tr>
</tbody>
</table>
<p>For the last information type - containers of individually-defined
key:value pairs - JADN provides two types: Map and Record. The
difference is that Record keys have a sequential ordering while Map keys
do not. Map instances are always serialized as key:value pairs, while
Record instances may be serialized as either key:value pairs or table
rows with values in column position, depending on data format.</p>
<p>For example if Location is a Record type with name, state, latitude
and longitude keys, its instances are serialized using <em>verbose</em>
JSON data format as:</p>
<div class="sourceCode" id="cb1"><pre
class="sourceCode json"><code class="sourceCode json"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ot">[</span></span>
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">{</span></span>
<span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a> <span class="dt">"name"</span><span class="fu">:</span> <span class="st">"St. Louis"</span><span class="fu">,</span></span>
<span id="cb1-4"><a href="#cb1-4" aria-hidden="true" tabindex="-1"></a> <span class="dt">"state"</span><span class="fu">:</span> <span class="st">"Missouri"</span><span class="fu">,</span></span>
<span id="cb1-5"><a href="#cb1-5" aria-hidden="true" tabindex="-1"></a> <span class="dt">"latitude"</span><span class="fu">:</span> <span class="st">"38.627003"</span><span class="fu">,</span></span>
<span id="cb1-6"><a href="#cb1-6" aria-hidden="true" tabindex="-1"></a> <span class="dt">"longitude"</span><span class="fu">:</span> <span class="st">"-90.199402"</span></span>
<span id="cb1-7"><a href="#cb1-7" aria-hidden="true" tabindex="-1"></a> <span class="fu">}</span><span class="ot">,</span></span>
<span id="cb1-8"><a href="#cb1-8" aria-hidden="true" tabindex="-1"></a> <span class="fu">{</span></span>
<span id="cb1-9"><a href="#cb1-9" aria-hidden="true" tabindex="-1"></a> <span class="dt">"name"</span><span class="fu">:</span> <span class="st">"Seattle"</span><span class="fu">,</span></span>
<span id="cb1-10"><a href="#cb1-10" aria-hidden="true" tabindex="-1"></a> <span class="dt">"state"</span><span class="fu">:</span> <span class="st">"Washington"</span><span class="fu">,</span></span>
<span id="cb1-11"><a href="#cb1-11" aria-hidden="true" tabindex="-1"></a> <span class="dt">"latitude"</span><span class="fu">:</span> <span class="st">"47.60621"</span><span class="fu">,</span></span>
<span id="cb1-12"><a href="#cb1-12" aria-hidden="true" tabindex="-1"></a> <span class="dt">"longitude"</span><span class="fu">:</span> <span class="st">"-122.33207"</span></span>
<span id="cb1-13"><a href="#cb1-13" aria-hidden="true" tabindex="-1"></a> <span class="fu">}</span></span>
<span id="cb1-14"><a href="#cb1-14" aria-hidden="true" tabindex="-1"></a><span class="ot">]</span></span></code></pre></div>
<p>The same Record values are serialized using <em>compact</em> JSON
data format (where the column positions are 1: name, 2: state, 3:
latitude, 4: longitude) as:</p>
<div class="sourceCode" id="cb2"><pre
class="sourceCode json"><code class="sourceCode json"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ot">[</span></span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a> <span class="ot">[</span><span class="st">"St. Louis"</span><span class="ot">,</span> <span class="st">"Missouri"</span><span class="ot">,</span> <span class="st">"38.627003"</span><span class="ot">,</span> <span class="st">"-90.199402"</span><span class="ot">],</span></span>
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a> <span class="ot">[</span><span class="st">"Seattle"</span><span class="ot">,</span> <span class="st">"Washington"</span><span class="ot">,</span> <span class="st">"47.60621"</span><span class="ot">,</span> <span class="st">"-122.33207"</span><span class="ot">]</span></span>
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a><span class="ot">]</span></span></code></pre></div>
<p>If Location is a Map type, its instances are always serialized as
key:value pairs regardless of data format, the same as a Record in
verbose JSON.</p>
<p>**</p>
<p>Another significant UML concept is that JADN distinguishes among all
four multiplicity types ([<a href="#uml">UML</a>], Table 7.1), while
logical models typically support only sets. Table 3-2 replicates the
information from UML Table 7.1 and adds the equivalent JADN types. Note
that the UML Specification cites the "traditional names" in its
"Collection Type" column.</p>