-
-
Notifications
You must be signed in to change notification settings - Fork 15
/
eml-semantics.xsd
245 lines (241 loc) · 14.7 KB
/
eml-semantics.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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:doc="eml://ecoinformatics.org/documentation-2.2.0" xmlns="eml://ecoinformatics.org/semantics-2.2.0" targetNamespace="eml://ecoinformatics.org/semantics-2.2.0">
<xs:import namespace="eml://ecoinformatics.org/documentation-2.2.0" schemaLocation="eml-documentation.xsd"/>
<xs:annotation>
<xs:documentation>
Copyright: 2017 Regents of the University of California
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-semantics</doc:moduleName>
<doc:moduleDescription>
<section xmlns="">
<title>
The eml-semantics module - Semantic annotations for formalized
statements about EML components
</title>
</section>
</doc:moduleDescription>
<doc:recommendedUsage>all datasets</doc:recommendedUsage>
<doc:standAlone>yes</doc:standAlone>
</doc:moduleDocs>
</xs:appinfo>
</xs:annotation>
<xs:complexType name="SemanticAnnotation">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Semantic annotation</doc:tooltip>
<doc:summary>A semantically-precise statement about an EML element.
</doc:summary>
<doc:description>
<section xmlns="">
<para>The SemanticAnnotation Type contains
elements that are used to associate a semantic statement using
a property and value from specific formal vocabularies with
other elements within EML. For example, one
might want to provide the precise set of semantic statements that
clarify the measurement semantics of an attribute (variable)
within a data set, or associate a specific statement with a
data table or dataset.
The eml-semantics module defines an 'annotation' element and
associated type that can be used within EML resources (dataset,
software, etc.), EML Entities (dataTable, spatialRaster,
spatialVector, otherEntity), and EML Attributes. They can also
be applied within the EML additionalMetadata field to label
arbitrary structures within EML, in which case the subject of
the annotation is the element listed in the describes element
within the additionalMetadata field.
</para>
</section>
</doc:description>
<doc:example>Please see the examples for the particular
subfields.</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="propertyURI" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Property URI</doc:tooltip>
<doc:summary>The persistent URI used to identify a property from a vocabulary.
</doc:summary>
<doc:description>The URI for a property that is drawn from a controlled
vocabulary, and that links the subject of this annotation
(which is implied by its parent element) to the annotation value.
The propertyURI represents a semantically well-defined concept
that one wants to apply to an element within EML.
These properties should be precisely defined,
including defining various relationships to related concepts.
Property URIs are typically drawn from formal ontologies that
provide well-defined logical semantics and provide for various
types of reasoning about equivalence and overlap.
Property URIs should be persistent and unique over decades,
and the meaning of the URI should
be stable over time as well. These URIs are usually constructed
using an additional abstraction layer via link resolvers,
rather than directly resolving to the term definition itself.
Thus, when resolving the propertyURI, software user agents should
be prepared to follow multiple redirects before finally
resolving the current location of the definition.
However, there is no requirement that propertyURIs need to be
resolvable, and metadata parsers should expect to find
propertyURIs that do not resolve and are only used as unique
URIs for the property (i.e., a name).
</doc:description>
<doc:example>http://ecoinformatics.org/oboe/oboe.1.2/oboe-characteristics.owl#ofCharacteristic</doc:example>
<doc:example>http://ecoinformatics.org/oboe/oboe.1.2/oboe-standards.owl#usesStandard</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="label" type="xs:string" use="required">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Property Label</doc:tooltip>
<doc:summary>
A human readable representation of the controlled property.
</doc:summary>
<doc:description>
A label that provides a human readable representation of
the controlled property. The label is often used to represent
the controlled property when displaying annotations in
software. The label is often redundant with one or more labels
that are defined in the controlled vocabulary itself,
but is repreated here within the EML document to make it easy
for consumers to display the annotation to users. Other
labels, including labels in multiple languages, may often be
accessible from within the ontology or controlled
vocabularly accessible at the propertyURI. Property definitions
and relationships to other properties are also typically
provided within the vocabularly accessible at the propertyURI.
Software and people may be able to resolve the URI to find out
the definition and retrieve additional labels and other metadata
for presentation to users.
</doc:description>
<doc:example>has characteristic</doc:example>
<doc:example>uses protocol</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="valueURI" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Value URI</doc:tooltip>
<doc:summary>The persistent URI used to identify a value from a vocabulary.
</doc:summary>
<doc:description>The URI for a value that is drawn from a controlled
vocabulary such as a published ontology or controlled term list. The
value represents the object of a semantic statement in which the
subject is the containing element, the property is defined by
the sibling propertyURI, and this valueURI element represents
the object. These values should be precisely defined,
including defining various relationships to related concepts.
Value URIs are typically drawn from formal ontologies that
provide well-defined logical semantics and provide for various
types of reasoning about value equivalence and overlap.
Value URIs should be persistent and unique over decades,
and the meaning of the values associated with the URI should
be stable over time as well. These URIs are usually constructed
using an additional abstraction layer via link resolvers,
rather than directly resolving to the term definition itself.
Thus, when resolving the valueURI, software user agents should
be prepared to follow multiple redirects before finally
resolving the current location of the value definition.
However, there is no requirement that valueURIs need to be
resolvable, and metadata parsers should expect to find
valueURIs that do not resolve and are only used as unique
URIs for the value (i.e., a name)
</doc:description>
<doc:example>http://ecoinformatics.org/oboe/oboe.1.2/oboe-characteristics.owl#Mass</doc:example>
<doc:example>http://ecoinformatics.org/oboe/oboe.1.2/oboe-standards.owl#Kilogram</doc:example>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="label" type="xs:string" use="required">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Value Label</doc:tooltip>
<doc:summary>
A human readable representation of the controlled value.
</doc:summary>
<doc:description>
A label that provides a human readable representation of
the controlled value. The label is often used to represent the
controlled value when displaying annotations in software. The
label is often redundant with one or more labels that are
defined in the controlled vocabulary itself, but is repreated
here within the EML document to make it easy for consumers to
display the annotation to users. Other labels, including
labels in multiple languages, may often be accessible from
within the ontology or controlled vocabularly accessible at
the valueURI. Value definitions and relationships to
other terms are also typically provided within the vocabularly
accessible at the valueURI. Software and people can resolve
the value URI to find out the definition of the value and
retrieve additional labels and other metadata about the value
for presentation to users.
</doc:description>
<doc:example>Mass</doc:example>
<doc:example>Kilogram</doc:example>
<doc:example>Net Primary Production</doc:example>
<doc:example>Carbon</doc:example>
<doc:example>Density</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="annotation" type="SemanticAnnotation">
<xs:annotation>
<xs:appinfo>
<doc:tooltip>Semantic Annotation</doc:tooltip>
<doc:summary>A precisely-defined semantic statement.
</doc:summary>
<doc:description>An annotation represents a precisely-defined semantic
statement that is used to semantically label another structure
within EML, such as an attribute, entity, or dataset. The annotation
is composed of a subject (implied by the element containing
the annotation or pointed at from within eml:additionalMetadata), a
property that defines the relationship between the
subject and the object of the statement, and the value of that
property. This is equivalent to RDF Statements that consist of a
Subject, Predicate, and Object. More concretely, the annotation
provides a way to state that an element within EML has a specific
property with a specific value.
</doc:description>
<doc:example>For example, a common annotation would state that a containing
'attribute' uses a measurement unit of 'grams'. This would be equivalent
to defining a statement using the OBOE design pattern that says:
'attribute7' 'oboe:usesStandard' 'oboe:Gram', where 'attribute7' is
shorthand for the attribute in EML containing the annotation, and
'oboe:' is shorthand for the full OBOE URI. In this example,
'attribute7' is the subject represented as the id of the attribute
containing the annotation, 'oboe:standard' is the propertyURI for the
statement, and 'oboe:Gram' is the object of the statement.
</doc:example>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:schema>