The eml module is a wrapper container that allows the inclusion of any metadata
content in a single EML document. The eml module is used as a container to hold
structured descriptions of ecological resources. In EML, the definition of a resource
comes from the
, which describes a general element set used to describe "networked digital
resources". The top-level structure of EML has been designed to be compatible with the
Dublin Core syntax. In general, dataset resources, literature resources, software
resources, and protocol resources comprise the list of information that may be
described in EML. EML is largely designed to describe digital resources, however, it
may also be used to describe non-digital resources such as paper maps and other
non-digital media. In EML, the definition of a "Data Package" is the
combination of both the data and metadata for a resource. So, data
packages are built by using the <eml> wrapper, which will include all of
the metadata, and optionally the data (or references to them). All EML packages must
begin with the <eml> tag and end with the </eml> tag.
The eml module may be extended to describe other resources by means of its
optional sub-field, <additionalMetadata>. This field is largely reserved
for the inclusion of metadata that may be highly discipline specific and not covered
in this version of EML, or it may be used to internally extend fields within the EML
standard.
Element Definitions:
|
eml
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
The "eml" element allows for the inclusion of any metadata content in a
single EML document. In general, dataset resources, literature resources, and software
resources, or another type that extends eml-resource are described using an eml document.
The eml document represents a "package" that can contain both metadata and data. It can
optionally include non-EML metadata through the flexibility of the "additionalMetadata"
element. Any additional metadata that is provided can provide a pointer into the EML
metadata indicating what the context of the additional metadata is (i.e., what it
describes). For example, a spatial raster image might be described in EML, and an FGDC
CSDGM metadata document could be included in the additionalMetadata element with a pointer
to the EML spatialRaster element to indicate that the FGDC metadata is providing
supplemental documentation about that particular image entity. There is no validity
constraint that restricts what metadata may be present in additionalMetadata.
|
access
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
An optional access tree at this location controls access to the entire metadata document. If this access element is omitted from the document, then the package submitter should be given full access to the package but all other users should be denied all access.
|
dataset
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
A resource that describes a data set, which can include one or more
data entities such as data tables and spatial images (raster and vector). If
included, this represents the primary resource that is described in this eml
document.
|
citation
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
A resource that describes a literature citation that one might find
in a bibliography. If included, this represents the primary resource that is
described in this eml document.
|
software
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
A resource that describes a software package, which can include
commercial and non-commercial software as well as data processing programs. If
included, this represents the primary resource that is described in this eml
document.
|
protocol
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
A resource that describes a scientific protocol, which can include
one or more descriptions of methods and procedures. If included, this represents
the primary resource that is described in this eml document.
|
additionalMetadata
| This element has no default value. |
| Content of this field: | Description of this field: |
| Elements: | Use: | How many: |
| A sequence of ( |
| describes | optional | unbounded |
| metadata | required | |
| ) |
| Attributes: | Use: | Default Value: |
| id | optional |
|
A flexible field for including any other relevant metadata that
pertains to the resource being described. This field allows EML to be extensible in
that any XML-based metadata can be included in this element, including metadata from
other standards such as the FGDC CSDGM. The "describes" element of this field allows
the specific part of the resource which is described by the additional metadata to
be indicated formally.
|
describes
| This element has no default value. |
| Content of this field: | Description of this field: |
|
|
A pointer to the id attribute for the sub-portion of the
resource that is described by this additional metadata. This is a formal field
in that it is an error to provide a value in the "describes" element that does
not correspond to the value of one of the "id" attributes in another eml
module. This is designed to allow automated processors to discover the
contextual relationship between the additional metadata and the resource it
describes.
Example(s):
knb.343.22
|
metadata
| This element has no default value. |
| Content of this field: | Description of this field: |
| Elements: | Use: | How many: |
| A sequence of ( |
| ) |
|
This element contains the additional metadata to be included in
the document. This element should be used for extending EML to include
metadata that is not already available in another part of the EML
specification, or to include site- or system-specific extensions that are
needed beyond the core metadata. The additional metadata contained in this
field describes the element referenced in the 'describes' element preceding
it. The content of this field is any well-formed XML fragment. If that content
contains namespace declarations, and if the namespace declaration can be
resolved to a schema definition, then the content will be validated against
that schema definition. If no namespace is present, or if no schema can be
resolved, validation for this fragment will be skipped (validation is "lax").
Example(s):
<embargoDate>2006-10-10</embargoDate>
|
Attribute Definitions:
|
id
|
|
Type: res:IDType
Use: optional
|
packageId
|
|
Type: xs:string
Use: required
|
A unique identifier for this entire EML metadata document that can be
used to reference it elsewhere. This identifier can be interpreted as the formal
accession number for this EML package, and is therefore required. It must be unique
within a particular data management system (see the "system" attribute).
Example(s):
knb.343.22
|
system
|
|
Type: res:SystemType
Use: required
|
scope
|
|
Type: res:ScopeType
|
The scope of the identifier. Scope is generally set to either "system",
meaning that it is scoped according to the "system" attribute, or "document" if it is
only to be in scope within this single document instance. In this particular use of
scope, it is FIXED to be "system" because the packageId is required and always has the
scope of the required "system".
Example(s):
system
|
xml:lang
|
|
Use: optional
|
Complex Type Definitions:
|