About projectDB Schema

This module is based on the eml-project module. It describes a project which might form a context for research. The definition of a "project" is not constrained. It may include scientific research investigations or student-led thesis projects, working groups of limited scope, or cyberinfrastructure coding projects. It is intended to house information on how a project was created, including descriptions of motivations and goals, funding, personnel, description of the study area or study design. This module also has descriptors for associated resources and projects, and for material intended for (or derived from) reports, and related to project management issues such as approval or permission.

Unlike the eml-project module, instance documents written against this schema are standalone documents; the lter:researchProject element is a top level element. It includes the "resource group" which includes basic elements for title, abstract, responsible parties, coverage, keywords, etc, as do other top-level EML resources.

Since it is derived from the EML-2.1.0 family of schemas, most namespaces were left unchanged. If an imported schema was edited to provide functionality for the lter-project schema, its namespace was updated to include the term 'lter-' to distinguish it from the namespaces used by EML.

The eml-resource module contains general information that describes dataset resources, literature resources, protocol resources, and software resources. Each of the above four types of resources share a common set of information, but also have information that is unique to that particular resource type. Each resource type uses the eml-resource module to document the information common to all resources, but then extend eml-resource with modules that are specific to that particular resource type. For instance, all resources have creators, titles, and perhaps keywords, but only the dataset resource would have a "data table" within it. Likewise, a literature resource may have an "ISBN" number associated with it, whereas the other resource types would not.

The eml-resource module is exclusively used by other modules, and is therefore not a stand-alone module.

The eml-physical module describes the external and internal physical characteristics of a data object as well as the information required for its distribution. Examples of the external physical characteristics of a data object would be the filename, size, compression, encoding methods, and authentication of a file or byte stream. Internal physical characteristics describe the format of the data object being described. Both named binary or otherwise proprietary formats can be cited (e.g., Microsoft Access 2000), or text formats can be precisely described (e.g., ASCII text delimited with commas). For these text formats, it also includes the information needed to parse the data object to extract the entity and its attributes from the data object. Distribution information describes how to retrieve the data object. The retrieval information can be either online (e.g., a URL or other connection information) or offline (e.g., a data object residing on an archival tape).

The eml-physical module, like other modules, may be "referenced" via the <references> tag. This allows a physical document to be described once, and then used as a reference in other locations within the EML document via its ID.

The eml-party module describes a responsible party (person or organization), and is typically used to name the originator of a resource or metadata document. It contains detailed contact information for the party, be it an individual person, an organization, or a named position within an organization. The eml-party module is used throughout the other EML modules where detailed contact information is needed.

The eml-party module, like other modules, may be "referenced" via the <references> tag. This allows a party to be described once, and then used as a reference in other locations within the EML document via its ID.

The eml-coverage module contains fields for describing the coverage of a resource in terms of time, space, and taxonomy. These coverages (temporal, spatial, and taxonomic) represent the extent of applicability of the resource in those domains. The Geographic coverage section allows for 2 means of expressing coverage on the surface of the earth: 1) via a set of bounding coordinates that define the North, South, East and West points in a rectangular area, optionally including a bounding altitude, and 2) using a G-Ring polygon definition, where an irregularly shaped area may be defined using a ordered list of latitude/longitude coordinates. A G-Ring may also include an "inner G-Ring" that defines one or more "cut-outs" in the area, i.e. the donut hole concept.

The temporal coverage section allows for the definition of either a single date/time, or a range of dates/times. These date/times may be expressed as a calendar date according to the ISO 8601 Date and Time Specification, or or by using an alternate time scale, such as the geologic time scale. In order to express an "ongoing" time frame, the end date in the range would likely use the alternate time scale fields with a value of "ongoing", whereas the begin date would use the specific calendar date fields.

The taxonomic coverage section allows for detailed description of the taxonomic extent of the dataset or resource. The taxonomic classification consists of a recursive set of taxon rank names, their values, and their common names. This construct allows for a taxonomic hierarchy to be built to show the level of identification (e.g. Rank Name = Kingdom, Rank Value = Animalia, Common Name = Animals, and so on down the hierarchy.) The taxonomic coverage module also allows for the definition of the classification system in cases where alternative systems are used.

The eml-coverage module, like other modules, may be "referenced" via the <references> tag. This allows the coverage extent to be described once, and then used as a reference in other locations within the EML document via its ID.

The eml-literature module contains information that describes literature resources. It is intended to provide overview information about the literature citation, including title, abstract, keywords, and contacts. Citation types follow the conventions laid out by EndNote, and there is an attempt to represent a compatible subset of the EndNote citation types. These citation types include: article, book, chapter, edited book, manuscript, report, thesis, conference proceedings, personal communication, map, generic, audio visual, and presentation. The "generic" citation type would be used when one of the other types will not work.

The eml-literature module, like other modules, may be "referenced" via the <references> tag. This allows a citation to be described once, and then used as a reference in other locations within the EML document via its ID.

The eml-access module describes the level of access that is to be allowed or denied to a resource for a particular user or group of users, and can be described independently for metadata and data. The eml-access module uses a reference to a particular authentication system to determine the set of principals (users or groups) that can be specified in the access rules. The special principal 'public' can be used to indicate that any user or group has access permission, thereby making it easier to specify that anonymous access is allowed.

There are two mechanisms for including access control via the eml-access module: 1) Each top-level resource module (eml-dataset, eml-literature, eml-software, and eml-protocol) may be accompanied by an optional <access> element that is used to establish the default access control at the resource level for the entire EML package. If this access element is ommitted from the document, then the package submitter should be given full access to the package but all other users should be denied all access. To allow the package to be publicly viewable, the EML author must explicitly include a rule stating so. 2) Exceptions for particular entity-level components of the package can be controlled at a finer grain by using an access description in that entity's physical/distribution tree. When access control rules are specified at this level, they apply only to the data in the parent distribution element, and not to the metadata. Thus, it will control access to the content of the <inline> element, as well as resources that are referenced by the <online/url> and <online/connection> elements. These exceptions to access for particular data resources are applied after the default access rules at the package-level have been applied, so they effectively override the default rules when they overlap.

In previous versions of EML access rules for entity-level distribution were contained in <additionalMetadata> sections and referenced via the <describes> tag. Although in theory these could have referenced any node, in application such node-level access control is problematic. Since the most common uses of access control rules were to limit access to specific data entities, the access tree has been placed there explicitly in EML 2.1.0.

Access is specified with a choice of child elements, either <allow> or <deny>. Within these rules, values can be assigned for each <principal> using the <permission> element. Users given "read" permission can view the resource; "write" allows changes to the resource excluding changes to the access rules; "changePermission" includes "write" plus the changing of access rules. Users allowed "all" permissions; may do all of the above.

An example is given below, with non-critical sections deleted:

  <eml>
      <access 
          authSystem="ldap://ldap.ecoinformatics.org:389/dc=ecoinformatics,dc=org" 
          order="allowFirst">
        <allow>
          <principal>uid=alice,o=NASA,dc=ecoinformatics,dc=org</principal>
          <permission>read</permission>
          <permission>write</permission>
        <allow>
      </access>
      <dataset>
      ...
      ...
      <dataTable id="entity123">
      ...
        <physical>
        ...
          <distribution>
          ...
            <access 
            authSystem="ldap://ldap.ecoinformatics.org:389/dc=ecoinformatics,dc=org" 
            order="allowFirst">
              <deny>
                <principal>uid=alice,o=NASA,dc=ecoinformatics,dc=org</principal>
                <permission>write</permission>
            </deny>
          </access>
         </distribution>
       </physical>
      </dataTable>
      <dataTable id="entity234">
        ...
        <physical>
        ...
          <distribution>
            ...
            <access>
              <references>entity123</references>
            </access>
          </distribution>
        </physical>
      </dataTable>
      ...    
    </dataset>
  <eml>

This example also shows how the eml-access module, like other modules, may be "referenced" via the <references> tag. This allows an access control document to be described once, and then used as a reference in other locations within the EML document via its ID.

In summary, access rules can be applied in two places in an eml document. Default access rules are established in the top <access> element for the main eml resource (e.g., "/eml/access"). These default rules can be overridden for particular data entities by adding additional <access> elements in the physical/distribution trees of those entities.