-
Notifications
You must be signed in to change notification settings - Fork 0
/
eml-attribute.xsd
1703 lines (1699 loc) · 89.3 KB
/
eml-attribute.xsd
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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:res="eml://ecoinformatics.org/resource-2.1.1" xmlns:doc="eml://ecoinformatics.org/documentation-2.1.1" xmlns:cit="eml://ecoinformatics.org/literature-2.1.1" xmlns:cov="eml://ecoinformatics.org/coverage-2.1.1" xmlns:md="eml://ecoinformatics.org/methods-2.1.1" xmlns="eml://ecoinformatics.org/attribute-2.1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:unit="eml://ecoinformatics.org/units-2.1.1" targetNamespace="eml://ecoinformatics.org/attribute-2.1.1">
<xs:import namespace="eml://ecoinformatics.org/documentation-2.1.1" schemaLocation="eml-documentation.xsd"/>
<xs:import namespace="eml://ecoinformatics.org/methods-2.1.1" schemaLocation="eml-methods.xsd"/>
<xs:import namespace="eml://ecoinformatics.org/coverage-2.1.1" schemaLocation="eml-coverage.xsd"/>
<xs:import namespace="eml://ecoinformatics.org/literature-2.1.1" schemaLocation="eml-literature.xsd"/>
<xs:import namespace="eml://ecoinformatics.org/resource-2.1.1" schemaLocation="eml-resource.xsd"/>
<xs:import namespace="eml://ecoinformatics.org/units-2.1.1" schemaLocation="eml-unitTypeDefinitions.xsd"/>
<xs:annotation>
<xs:documentation>
'$RCSfile: eml-attribute.xsd,v $'
Copyright: 1997-2002 Regents of the University of California,
University of New Mexico, and
Arizona State University
Sponsors: National Center for Ecological Analysis and Synthesis and
Partnership for Interdisciplinary Studies of Coastal Oceans,
University of California Santa Barbara
Long-Term Ecological Research Network Office,
University of New Mexico
Center for Environmental Studies, Arizona State University
Other funding: National Science Foundation (see README for details)
The David and Lucile Packard Foundation
For Details: http://knb.ecoinformatics.org/
'$Author: obrien $'
'$Date: 2009-02-25 23:51:54 $'
'$Revision: 1.123 $'
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
</xs:documentation>
<xs:appinfo>
<doc:moduleDocs>
<doc:moduleName>eml-attribute</doc:moduleName>
<doc:moduleDescription>
<section xmlns="">
<title>
The eml-attribute module - Attribute level information within
dataset entities
</title>
<para>
The eml-attribute module describes all attributes (variables)
in a data entity: dataTable, spatialRaster, spatialVector,
storedProcedure, view or otherEntity. The description includes the
name and definition of each attribute, its domain, definitions of
coded values, and other pertinent information. Two structures exist
in this module: 1. attribute is used to define a single attribute;
2. attributeList is used to define a list of attributes that go
together in some logical way.
</para>
<para>
The eml-attribute module, like other modules, may be
"referenced" via the <references> tag. This
allows an attribute document to be described once, and then
used as a reference in other locations within the EML document
via its ID.
</para>
<section>
<title>Philosophy of Attribute Units</title>
<para>The concept of "unit" represents one of the most fundamental
categories of metadata. The classic example of data entropy is the
case in which a reported numeric value loses meaning due to lack of
associated units. Much of Ecology is driven by measurement, and
most measurements are inherently comparative. Good data description
requires a representation of the basis for comparison, i.e., the
unit. In modeling the attribute element, the authors of EML drew
inspiration from the
<ulink url="http://physics.nist.gov/cuu/Units/introduction.html">
NIST Reference on Constants, Units, and Uncertainty</ulink>.
This document defines a unit as "a particular physical quantity,
defined and adopted by convention, with which other particular
quantities of the same kind are compared to express their value."
The authors of the EML 2.0 specification (hereafter "the authors")
decided to make the unit element required, wherever
possible.</para>
<para>Units may also be one of the most problematic categories of
metadata. For instance, there are many candidate attributes that
clearly have no units, such as named places and letter grades.
There are other candidate attributes for which units are difficult
to identify, despite some suspicion that they should exist (e.g.
pH, dates, times). In still other cases, units may be meaningful,
but apparently absent due to dimensional analysis (e.g. grams of
carbon per gram of soil). The relationship between units and
dimensions likewise is not completely clear.</para>
<para>The authors decided to sharpen the model of attribute by
nesting unit under measurementScale. Measurement Scale is a data
typology, borrowed from Statistics, that was introduced in the
1940's. Under the adopted model, attributes are classified as
nominal, ordinal, interval, and ratio. Though widely criticized,
this classification is well-known and provides at least first-order
utility in EML. For example, nesting unit under measurementScale
allows EML to prevent its meaningless inclusion for categorical
data -- an approach judged superior to making unit universally
required or universally optional.</para>
<para>The sharpening of the attribute model allowed the elimination
of the unit type "undefined" from the standard unit dictionary (see
eml-unitDictionary.xml). It seemed self-defeating to require the
unit element exactly where appropriate, yet still allow its content
to be undefined. An attribute that requires a unit definition is
malformed until one is provided. The unit type "dimensionless" is
preserved, however. In EML 2.0, it is synonymous with "unitless"
and represents the case in which units cannot be associated with an
attribute for some reason, despite the proper classification of
that attribute as interval or ratio. Dimensionless may itself be an
anomaly arising from the limitations of the adopted measurement
scale typology.</para>
<para>Closely related to the concept of unit is the concept of
attribute domain. The authors decided that a well-formed
description of an attribute must include some indication of the set
of possible values for that attribute. The set of possible values
is useful, perhaps necessary, for interpreting any particular
observed value. While universally required, attribute domain has
different forms, depending on the associated measurement
scale.</para>
<para>The element storageType has an obvious relationship to
domain. It gives some indication of the range of possible values of
an attribute, and also gives some (potentially critical)
operability information about the way the attribute is represented
or construed in the local storage system. The storageType element
seems to fall in a gray area between the logical and physical
aspects of stored data. Neither comfortable with eliminating it nor
with making it required, the authors left it available but optional
under attribute. In addition, it is repeatable so that different
storage types can be provided for various systems (e.g., different
databases might use different types for columns, even though the
domain of the attribute is the same regardless of which database
is used).</para>
<para>Attributes representing dates, times, or combinations thereof
(hereafter "dateTime") were the most difficult to model in EML. Is
dateTime of type interval or ordinal? Does it have units or not?
Strong cases can be made on each side of the issue. The confusion
may reflect the limitations of the measurement scale typology. The
final resolution of the dateTime model is probably somewhat
arbitrary. There was clearly a need, however, to allow for the
interoperability of dateTime formats. EML 2.0 tries to provide an
unambiguous mechanism for describing the format of dateTime
values by providing a separate category for date and time values. This
"dateTime" measurement scale allows users to explicitly label
attributes that contain Gregorian date and time values, and allows
them to provide the information needed to parse these values into
their appropriate components (e.g., days, months, years)./</para>
</section>
</section>
</doc:moduleDescription>
<doc:recommendedUsage>any dataset that uses dataTable, spatialRaster,
spatialVector, storedProcedure, view or otherEntity or in a custom
module where one wants to document an attribute
(variable)</doc:recommendedUsage>
<doc:standAlone>yes</doc:standAlone>
</doc:moduleDocs>
</xs:appinfo>
</xs:annotation>
<xs:element name="attribute" type="AttributeType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute</doc:tooltip>
<doc:summary>Characteristics of a 'field' or 'variable' in a data
entity (ie. dataTable).</doc:summary>
<doc:description>The content model for attribute is a CHOICE between
"references" and all of the elements that let you describe the
attribute (e.g., attributeName, attributeDefinition, precision). The
attribute element allows a user to document the characteristics that
describe a 'field' or 'variable' in a data entity (e.g. dataTable).
Complete attribute descriptions are perhaps the most important aspect
to making data understandable to others. An attribute element describes
a single attribute or an attribute element can contain a reference
to an attribute defined elsewhere. Using a reference means that the
referenced attribute is (semantically) identical, not just in name
but identical in its complete description. For example, if attribute
"measurement1" in dataTable "survey1" has a precision of 0.1 and
you are documenting dataTable survey2 which has an attribute called
"measurement1" but the survey2's measurement1 has a precision of
0.001 then these are different attributes and must be described
separately.</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:complexType name="AttributeListType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute List</doc:tooltip>
<doc:summary>List of attributes</doc:summary>
<doc:description>This complexType defines the structure of the
attributeList element. The content model is a choice between one or
more attribute elements, and references. References links to an
attribute list defined elsewhere.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:choice>
<xs:element name="attribute" type="AttributeType" maxOccurs="unbounded"/>
<xs:group ref="res:ReferencesGroup"/>
</xs:choice>
<xs:attribute name="id" type="res:IDType" use="optional"/>
</xs:complexType>
<xs:complexType name="AttributeType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute Type</doc:tooltip>
<doc:summary>
Type definition for the content of an attribute (variable)
that can be part of an entity.
</doc:summary>
<doc:description> Type definition for the content of an
attribute (variable) that can be part of an entity.
</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:choice>
<xs:sequence>
<xs:element name="attributeName" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute name</doc:tooltip>
<doc:summary>The name of the attribute
</doc:summary>
<doc:description>Attribute name is official name of the
attribute. This is usually a short, sometimes cryptic name
that is used to refer to the attribute. Many systems have
restrictions on the length of attribute names, and on the
use of special characters like spaces in the name, so the
attribute name is often not particularly useful for display
(use attributeLabel for display). The attributeName is
usually the name of the variable that is found in the header
of a data file.
</doc:description>
<doc:example>spden</doc:example>
<doc:example>spatialden</doc:example>
<doc:example>site</doc:example>
<doc:example>spcode</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="attributeLabel" type="res:NonEmptyStringType" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute label</doc:tooltip>
<doc:summary>A label for displaying an attribute name.
</doc:summary>
<doc:description>A descriptive label that can be used to display
the name of an attribute. This is often a longer, possibly
multiple word name for the attribute than the attributeName. It
is not constrained by system limitations on length or special
characters. For example, an attribute with a name of 'spcode'
might have an attributeLabel of 'Species Code'.
</doc:description>
<doc:example>Species Density</doc:example>
<doc:example>Spatial Density</doc:example>
<doc:example>Name of Site</doc:example>
<doc:example>Species Code</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="attributeDefinition" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute definition</doc:tooltip>
<doc:summary>Precise definition of the attribute
</doc:summary>
<doc:description>This element gives a precise definition of
attribute in the data entity (dataTable, spatialRaster,
spatialVector, storedProcedure, view or otherEntity) being
documented. It explains the contents of the attribute fully so
that a data user could interpret the attribute accurately.
Some additional information may also be found in the
methods element as well.
</doc:description>
<doc:example>"spden" is the number of individuals of all
macro invertebrate species found in the plot</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="storageType" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Storage Type</doc:tooltip>
<doc:summary>Storage type hint for this field</doc:summary>
<doc:description>This element describes the storage type,
for data in a RDBMS (or other data management system) field.
As many systems do not
provide for fine-grained restrictions on types, this type will
often be a superset of the allowed domain defined in
attributeDomain. Values for this field are by default drawn from
the XML Schema Datatypes standard values, such as: integer,
double, string, etc. If the XML Schema Datatypes are not used,
the type system from which the values are derived should be
listed in the 'typeSystem' attribute described below. This field
represents a 'hint' to processing systems as to how the attribute
might be represented in a system or language, but is distinct
from the actual expression of the domain of the attribute. The
field is repeatable so that the storageType can be indicated for
multiple type systems (e.g., Oracle data types and Java data
types).</doc:description>
<doc:example>integer</doc:example>
<doc:example>int</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="typeSystem" type="xs:string" use="optional" default="http://www.w3.org/2001/XMLSchema-datatypes">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Storage Type System</doc:tooltip>
<doc:summary>The system used to define the storage types.
This should be an identifier of a well known and
published typing system.</doc:summary>
<doc:description>The typeSystem attribute is the system
used to define the storage types. This should be an
identifier of a well known and published typing system.
The default and recommended system is the XML Schema data
type system. For details go to http://www.w3.org. If
another system is used (such as Java or C++ types),
typeSystem should be changed to match the
system.</doc:description>
<doc:example>
http://www.w3.org/2001/XMLSchema-datatypes</doc:example>
<doc:example>java</doc:example>
<doc:example>C</doc:example>
<doc:example>Oracle 8i</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="measurementScale">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Measurement Scale</doc:tooltip>
<doc:summary>The measurement scale for the attribute.
</doc:summary>
<doc:description>The measurementScale element indicates the
type of scale from which values are drawn for the
attribute. This provides information about the scale in
which the data was collected.</doc:description>
<doc:example>Nominal is used when numbers have only been assigned
to a variable for the purpose of categorizing the
variable. An example of a nominal scale is assigning the
number 1 for male and 2 for female.</doc:example>
<doc:example>Ordinal is used when the categories have a logical
or ordered relationship to each other. These types of scale
allow one to distinguish the order of values, but not the
magnitude of the difference between values. An example of an
ordinal scale is a categorical survey where you rank a variable
1=good, 2=fair, 3=poor.</doc:example>
<doc:example>Interval is used for data which consist of
equidistant points on a scale. The Celsius scale is an interval
scale, since each degree is equal but there is no natural
zero point (so, 20 C is not twice as hot as 10 C).
</doc:example>
<doc:example>Ratio is used for data which consists not only of
equidistant points but also has a meaningful zero
point, which allows ratios to have meaning. An example of a
ratio scale would be the Kelvin temperature scale (200K is
half as hot as 400K), and length in
meters (e.g., 10 meters is twice as long as 5 meters).
</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:choice>
<xs:element name="nominal">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Nominal scale</doc:tooltip>
<doc:summary>Characteristics used to define nominal
(categorical) scale attributes</doc:summary>
<doc:description>This field is used for defining the
characteristics of this variable if it is a
nominal scale variable, which are variables that are
categorical in nature.
Nominal is used when numbers have only been
assigned to a variable for the purpose of categorizing the
variable. An example of a nominal scale is assigning the
number 1 for male and 2 for female.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="nonNumericDomain" type="NonNumericDomainType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ordinal">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Ordinal scale</doc:tooltip>
<doc:summary>Characteristics used to define ordinal
(ordered) scale attributes</doc:summary>
<doc:description>This field is used for defining the
characteristics of this variable if it is an
ordinal scale variable, which specify ordered values
without specifying the magnitude of the difference between
values. Ordinal is used when the categories have
a logical or ordered relationship to each other. These
types of scale allow one to distinguish the order
of values, but not the magnitude of the difference
between values. An example of an ordinal scale is a
categorical survey where you rank a variable 1=good,
2=fair, 3=poor.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="nonNumericDomain" type="NonNumericDomainType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="interval">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Interval scale</doc:tooltip>
<doc:summary>Characteristics used to define interval
scale attributes</doc:summary>
<doc:description>This field is used for defining the
characteristics of this variable if it is an
interval scale variable, which specifies both the order
and magnitude of values, but has no natural zero point.
Interval is used for data which consist of
equidistant points on a scale. The Celsius scale is an
interval scale, since each degree is equal but there is
no natural zero point (so, 20 C is not twice as hot as
10 C). zero point (so, 20 C is not twice as hot as 10
C).</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="unit" type="UnitType"/>
<xs:element name="precision" type="PrecisionType" minOccurs="0"/>
<xs:element name="numericDomain" type="NumericDomainType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ratio">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Ratio scale</doc:tooltip>
<doc:summary>Characteristics used to define ratio
scale attributes</doc:summary>
<doc:description>This field is used for defining the
characteristics of this variable if it is a
ratio scale variable, which specifies the order and
magnitude of values and has a natural zero point, allowing
for ratio comparisons to be valid.
Ratio is used for data which consists not
only of equidistant points but also has a meaningful zero
point, which allows ratios to have meaning. An example
of a ratio scale would be the Kelvin temperature scale
(200K is half as hot as 400K), and length in meters (e.g.,
10 meters is twice as long as 5 meters).</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="unit" type="UnitType"/>
<xs:element name="precision" type="PrecisionType" minOccurs="0"/>
<xs:element name="numericDomain" type="NumericDomainType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dateTime">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Date/Time scale</doc:tooltip>
<doc:summary>Characteristics used to define date and
time attributes</doc:summary>
<doc:description>
<para xmlns="">The dateTime field is used for defining the
characteristics of the attribute if it contains
date and time values. DateTime is used when the values
fall on the Gregorian calendar system. DateTime values
are special because the have properties of interval
values (most of the time it is legitimate to treat them
as interval values by converting them to a duration from
a fixed point) but they sometimes only behave as ordinals
(because the calendar is not predetermined, for some
dateTime values one can only find out the order of
the points and not the magnitude of the duration
between those points). Thus, the dateTime scale provides
the information necessary to properly understand and
parse date and time values without improperly
labeling them under one of the more traditional scales.</para>
<para xmlns="">Date and time values are unlike any other measured values.
Note that the dateTime field would not be used if
one is recording time durations. In that case, one should use a
standard unit such as seconds, nominalMinute or nominalDay, or a
customUnit that defines the unit in terms of its relationship to
SI second.</para>
</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="formatString" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Date/Time Format</doc:tooltip>
<doc:summary>A format string that describes the
format for a date-time value from the Gregorian
calendar.</doc:summary>
<doc:description>
<para xmlns="">A format string that describes
the format for a dateTime value from the
Gregorian calendar. DateTime values should be
expressed in a format that conforms to the ISO
8601 standard. This field allows one to specify
the format string that should be used to decode
the date or time value. To describe the format
of an attribute containing dateTime values,
construct a string representation of the format
using the following symbols:
</para>
<para xmlns="">
<literalLayout>
Y year
M month
W month abbreviation (e.g., JAN)
D day
h hour
m minute
s second
T time designator (demarcates date and time parts of date-time)
Z UTC designator, indicating value is in UTC time
. indicates a decimal fraction of a unit
+/- indicates a positive or negative number,
or a positive or negative time zone adjustment relative to UTC
- indicates a separator between date components
A/P am or pm designator
</literalLayout>
</para>
<para xmlns="">
Any other character in the format string is interpreted as a
separator character. Here are some examples of the format
strings that can be constructed.
</para>
<para xmlns="">
<literalLayout>
Format string Example value
------------------- ------------------
ISO Date YYYY-MM-DD 2002-10-14
ISO Datetime YYYY-MM-DDThh:mm:ss 2002-10-14T09:13:45
ISO Time hh:mm:ss 17:13:45
ISO Time hh:mm:ss.sss 09:13:45.432
ISO Time hh:mm.mm 09:13.42
Non-standard DD/MM/YYYY 14/10/2002
Non-standard MM/DD/YYYY 10/14/2002
Non-standard MM/DD/YY 10/14/02
Non-standard YYYY-WWW-DD 2002-OCT-14
Non-standard YYYYWWWDD 2002OCT14
Non-standard YYYY-MM-DD hh:mm:ss 2002-10-14 09:13:45
</literalLayout>
</para>
<para xmlns="">
Some notes about these examples. First, the ISO 8601 standard is
strict about the order of date components and the separators that
are legal. Best practice is to follow the ISO 8601 format
precisely. However, we recognize that existing data contain
non-standard dates, and existing equipment (e.g., sensors) may
still be producing non-standard dates. Consequently, we have
provided the formatting string with additional characters to
describe the date formats. In particular note that the use of a
slash (/) to separate date components, a space to separate date
and time components, using a twelve-hour time with am/pm
designator, and placing any of the components out of
descending order is non-standard according to ISO. Nevertheless,
these formats can be described using the format string to
accommodate existing data.
</para>
<para xmlns="">
Decimal dateTime values can be extended by indicating in
the format that additional decimals can be used. Only the final
unit (e.g., seconds in a time value) can use the extended digits
according to the ISO 8601 standard. For example, to show
indicate that seconds are represented to the nearest 1/1000
of a second, the format string would be "hh:mm:ss.sss".
Note that this only indicates the number of decimals used to
record the value, and not the precision of the measurement
(see dateTimePrecision for that).
</para>
<para xmlns="">
Date and time values are from an interval scale, but it is extremely
complex because of the vagaries of the calendar (e.g., leap
years, and leap seconds). The duration between date and time values
in the future is not even deterministic because leap seconds are
based on current measurements of the earth's orbit. Consequently,
date and time values are unlike any other measured values. The format
string for dateTime values allows one to accurately calculate the
duration in SI second units between two measured dateTime values,
assuming that the conversion software has a detailed knowledge of
the Gregorian calendar.
</para>
</doc:description>
<doc:example>YYYY-MM-DDThh:mm:ss</doc:example>
<doc:example>YYYY-MM-DD</doc:example>
<doc:example>YYYY</doc:example>
<doc:example>hh:mm:ss</doc:example>
<doc:example>hh:mm:ss.sss</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="dateTimePrecision" type="res:NonEmptyStringType" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>DateTime Precision</doc:tooltip>
<doc:summary>An indication of the precision of a
date or time value</doc:summary>
<doc:description>A quantitative indication of
the precision of a date or time measurement.
The precision should be interpreted in the
smallest units represented by the dateTime format.
For example, if a dateTime value has a format of
"hh:mm:ss.sss", then "seconds" are the smallest unit
and the precision should be expressed in seconds.
Thus, a precision value of "0.01" would mean that
measurements were precise to the nearest hundredth
of a second, even though the format string might
indicate that values were written down with 3
decimal places.</doc:description>
<doc:example>0.1</doc:example>
<doc:example>0.01</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="dateTimeDomain" type="DateTimeDomainType" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>DateTime Domain</doc:tooltip>
<doc:summary>See the summary for the type: DateTimeDomainType</doc:summary>
<doc:description>See the description for the type: DateTimeDomainType</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="missingValueCode" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Character for missing value</doc:tooltip>
<doc:summary>Character for missing value in the data of the
field</doc:summary>
<doc:description>This element is to specify missing value in the
data of the field. It is repeatable to allow for multiple
different codes to be present in the attribute. Note that missing
value codes should not be considered when determining if the
observed values of an attribute all fall within the domain
of the attribute (i.e., missing value codes should be parsed out
of the data stream before examining the data for domain
violations.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="code" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>The missing value code itself.</doc:tooltip>
<doc:summary>The missing value code itself.</doc:summary>
<doc:description>The code element is the missing value code
itself. Each missing value code should be entered in a
separate element instance. The value entered is what is
placed into a data grid if the value is missing for some
reason.</doc:description>
<doc:example>-9999</doc:example>
<doc:example>-1</doc:example>
<doc:example>N/A</doc:example>
<doc:example>MISSING</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="codeExplanation" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Explanation of Missing value Code</doc:tooltip>
<doc:summary>An explanation of what the missing value code
means.</doc:summary>
<doc:description>The codeExplanation element is an
explanation of the meaning of the missing value code that
was used, that is, the reason that there is a missing
value. For example, an attribute might have a missing
value code of '-99' to indicate that the data observation
was not actually taken, and a code of '-88' to indicate
that the data value was removed because of
calibration errors.</doc:description>
<doc:example>Sensor down time.</doc:example>
<doc:example>Technician error.</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="accuracy" type="Accuracy" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>The accuracy of the measured attribute</doc:tooltip>
<doc:summary>The accuracy of the attribute. This information
should describe any accuracy information that is known about the
collection of this data attribute.</doc:summary>
<doc:description>The accuracy element represents the accuracy of
the attribute. This information should describe any accuracy
information that is known about the collection of this data
attribute. The content model of this metadata is taken directly
from FGDC FGDC-STD-001-1998 section 2 with the exception of
processContact, sourceCitation, and timePeriodInformation which
either user XMLSchema types or use predefined EML types for these
purposes.</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="coverage" type="cov:Coverage" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute coverage</doc:tooltip>
<doc:summary>An explanation of the coverage of the attribute.
</doc:summary>
<doc:description>An explanation of the coverage of the attribute.
This specifically indicates the spatial, temporal, and taxonomic
coverage of the attribute in question when that coverage deviates
from coverages expressed at a higher level (e.g., entity or
dataset). Please see the eml-coverage module for complete
documentation.
</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="methods" type="md:MethodsType" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute methods</doc:tooltip>
<doc:summary>An explanation of the methods involved in the
collection of this attribute.</doc:summary>
<doc:description>An explanation of the methods involved in the
collection of this attribute. These specifically supplement or
possibly override methods provided at a higher level such as
entity or dataset.
Please see the eml-methods module for complete documentation.
</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:group ref="res:ReferencesGroup"/>
</xs:choice>
<xs:attribute name="id" type="res:IDType" use="optional"/>
<xs:attribute name="system" type="res:SystemType" use="optional"/>
<xs:attribute name="scope" type="res:ScopeType" use="optional" default="document"/>
</xs:complexType>
<xs:complexType name="Accuracy">
<xs:sequence>
<xs:element name="attributeAccuracyReport" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute Accuracy Report</doc:tooltip>
<doc:summary>An explanatory report of the accuracy of the
attribute.</doc:summary>
<doc:description>The attributeAccuracyReport element is an
explanation of the accuracy of the observation recorded in this
attribute. It will often include a description of the tests used to
determine the accuracy of the observation. These reports are
generally prepared for remote sensing or other measurement
devices.</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="quantitativeAttributeAccuracyAssessment" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Quantitative Attribute Accuracy
Assessment</doc:tooltip>
<doc:summary>A value assigned to summarize the accuracy of the
attribute.</doc:summary>
<doc:description>The quantitativeAttributeAccuracyAssessment
element is composed of two parts, a value that represents the
accuracy of the recorded observation an explanation of the tests
used to determine the accuracy.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="attributeAccuracyValue" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute Accuracy Value</doc:tooltip>
<doc:summary>A value assigned to estimate the accuracy of the
attribute.</doc:summary>
<doc:description>The attributeAccuracyValue element is an
estimate of the accuracy of the identification of the
entities and assignments of attribute values in the data set.
</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="attributeAccuracyExplanation" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute Accuracy Explanation</doc:tooltip>
<doc:summary>The test which yields the Attribute Accuracy
Value.</doc:summary>
<doc:description>The attributeAccuracyExplanation element is
the identification of the test that yielded the Attribute
Accuracy Value.</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="attributeList" type="AttributeListType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Attribute list</doc:tooltip>
<doc:summary>A list of attributes</doc:summary>
<doc:description>This is the root element of the eml-attribute module.
It is mainly used for testing, but can also be used for creating
stand-alone eml-attribute modules where a list of attributes is
needed.</doc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:complexType name="UnitType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Unit of measurement</doc:tooltip>
<doc:summary>Unit of measurement for data in the
field</doc:summary>
<doc:description>This field identifies the unit of measurement
for this attribute. It is a choice of either a standard unit,
or a custom unit. If it is a custom unit,
the definition of the unit must be provided in the document using
the STMML syntax, and the name provided in the customUnit element must
reference the id of its associated STMML definition precisely. For
further information on STMML (http://www.xml-cml.org/stmml/) or
see stmml.xsd which is included with the EML 2.0 distribution for
details.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:choice>
<xs:element name="standardUnit" type="unit:StandardUnitDictionary">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Standard Unit</doc:tooltip>
<doc:summary>The name of a standard unit used to make this
measurement</doc:summary>
<doc:description>Use the standardUnit element if the unit for this attribute has
been defined in the Standard Unit Dictionary.
The list of "standard" units includes the SI base units and many compound units based
on SI, plus and some commonly used units which are not SI. The list is by no means
exhaustive. If the unit you need is not part of this list, then the customUnit field should be used
instead. Standard units have been described using STMML. See the documentation
for the Type for more information.</doc:description>
<doc:example>meter</doc:example>
<doc:example>second</doc:example>
<doc:example>joule</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="customUnit" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Custom Unit</doc:tooltip>
<doc:summary>The name of a custom unit used to make this
measurement.</doc:summary>
<doc:description>The customUnit element is for units that are
not part of the standard list provided with EML. The customUnit
must correspond to an id in the
document where its definition is provided using the STMML
syntax. The customUnit definition will most likely be in
the additionalMetadata section.</doc:description>
<doc:example>gramsPerOneThirdMeter</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:choice>
</xs:complexType>
<xs:complexType name="PrecisionType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Precision</doc:tooltip>
<doc:summary>The precision of the measurement.</doc:summary>
<doc:description>Precision indicates how close together or how
repeatable measurements are. A precise measuring instrument will give
very nearly the same result each time it is used. This means that
someone interpreting the data should expect that if a measurement were
repeated, most measured values would fall within the interval specified
by the precision. The value of precision should be expressed in the
same unit as the measurement. For example, for an attribute with unit
"meter", a precision of "0.1" would be interpreted to mean that most
repeat measurements would fall within an interval of 1/10th of a meter.
</doc:description>
<doc:example>0.1</doc:example>
<doc:example>0.5</doc:example>
<doc:example>1</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:float"/>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="NonNumericDomainType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Non-numeric domain</doc:tooltip>
<doc:summary/>
<doc:description>The non-numeric domain field describes the domain
of the attribute being documented. It can describe two
different types of domains: enumerated and text. Enumerated
domains are lists of values that are explicitly provided as
legitimate values. Only values from that list should occur
in the attribute. They are often used for response codes
such as "HIGH" and "LOW". Text domains are used for attributes
that allow more free-form text fields, but still permit some
specification of the value-space through pattern matching. A
text domain is usually used for comment and notes attributes,
and other character attributes that don't have a precise set of
constrained values. This is an important field for post processing
and error checking of the dataset. It represents a formal
specification of the value space for the attribute, and so there
should never be a value for the attribute that falls outside of
the set of values prescribed by the domain.</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:choice>
<xs:choice maxOccurs="unbounded">
<xs:element name="enumeratedDomain">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Enumerated domain</doc:tooltip>
<doc:summary>Description of any coded values associated
with the attribute.</doc:summary>
<doc:description>The enumeratedDomain element describes
any code that is used as a value of an attribute. These
codes can be defined here in the metadata as a list with
definitions (preferred), can be referenced by pointing to
an external citation or URL where the codes are defined,
or can be referenced by pointing at an entity that contains
the code value and code definition as two attributes. For
example, data might have a variable named 'site' with
values 'A', 'B', and 'C', and the enumeratedDomain would
explain how to interpret those codes.
</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:choice>
<xs:element name="codeDefinition" maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Code Definition</doc:tooltip>
<doc:summary>A codes and its definition</doc:summary>
<doc:description>This element gives the value of a
particular code and its definition. It is repeatable
to allow for a list of codes to be provided.
</doc:description>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="code" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Code</doc:tooltip>
<doc:summary>Code value allowed in the
domain</doc:summary>
<doc:description>The code element specifies a
code value that can be used in the domain
</doc:description>
<doc:example>1</doc:example>
<doc:example>HIGH</doc:example>
<doc:example>BEPA</doc:example>
<doc:example>24</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="definition" type="res:NonEmptyStringType">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Code definition</doc:tooltip>
<doc:summary>Definition of the associated code
</doc:summary>
<doc:description>The definition describes the
code with which it is associated in enough