https://wiki.esipfed.org/w/api.php?action=feedcontributions&user=NanGalbraith&feedformat=atomEarth Science Information Partners (ESIP) - User contributions [en]2024-03-28T21:34:37ZUser contributionsMediaWiki 1.35.14https://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-3&diff=48586Attribute Convention for Data Discovery 1-32015-01-06T18:53:58Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div>[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
= Context =<br />
<br />
== Document ==<br />
<br />
This is the Attribute Convention for Data Discovery (ACDD).<br />
<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.3; it is the latest released version.<br />
<br />
The page [[Attribute Convention for Data Discovery]] always points to the current released version of the Convention. The version number at the top of the resulting page will show the current version.<br />
<br />
See the [http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery ACDD category page] for information on the history and maintenance of this convention.<br />
<br />
=== Development ===<br />
<br />
For development versions of the ACDD, please see the page [[Attribute Convention for Data Discovery Working]].<br />
<br />
Questions about this specification may be addressed to the [http://www.lists.esipfed.org/mailman/listinfo/esip-documentation ESIP Documentation Cluster mailing list].<br />
<br />
= Overview =<br />
This document describes attributes recommended for describing a NetCDF dataset to discovery systems such as Digital Libraries. THREDDS and other tools can use these attributes to extract metadata from datasets, and exporting to Dublin Core, DIF, ADN, FGDC, ISO 19115 and other metadata formats. This will help systems and users locate and use data efficiently.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cfconventions.org/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines three, title, history, and Conventions. CF specifies more: institution, source, references, comment, and featureType. ACDD 1.3 adopts all CF 1.6 global attributes. In a change from ACDD 1.1, we adopt the NUG recommendation to supply all conventions in the single Conventions attribute.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so similar terms exist in many metadata standards. This [[Attribute_Convention_for_Data_Discovery_(ACDD)_Mappings]] page includes a crosswalk to THREDDS, OGC CSW, ISO 19115-2 and Rubric Categories.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
Documents using other metadata specifications (e.g., ISO 19115) can provide additional information about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Definitions: Data and Metadata ==<br />
<br />
In several ACDD attribute names or definitions, the terms 'data' and 'metadata' are used. In the context of NetCDF files, these refer specifically to the values within the file, and the attributes of the file, respectively.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes characterize the data they are associated with. Any processing that alters these characteristics is responsible for updating the relevant attributes.<br />
<br />
NetCDF file creators and software developers should ensure that the attributes of output data accurately represent that data, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF data users should verify critical attribute values, to be confident the source metadata is appropriate.<br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables. These attributes are recommended, despite being redundant, because they greatly simplify data discovery and access.<br />
<br />
The risk of inconsistency between these attributes and the actual data is highest after aggregation or subsetting; checking them against the data can serve as a useful test of the metadata's validity.<br />
<br />
== Attribute Content Guidance ==<br />
<br />
=== Date and Time: ISO 8601 Recommended Formats ===<br />
<br />
The ACDD specifies [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601:2004] date and time formats for its temporal attributes. ACDD strongly encourages the use of the 'extended' format date-time, in the form <br />
<tt>YYYY-MM-DDThh:mm:ss<zone></tt><br />
(although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, or ±hh). Per the standard, the shortened or basic format, which omits the - and : separators, "should be avoided in plain text."<br />
<br />
For duration attributes, again the extended form is strongly encouraged for readability:<br />
<tt>P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]</tt><br />
<br />
If for some reason the strongly encouraged formats can not be used, other ISO 8601-compatible formats are acceptable, but may not be handled by some processing software.<br />
<br />
=== Comma-Separated Lists ===<br />
<br />
Several attributes explicitly allow the entry of multiple entities as comma-separated values. Any entities within such lists which contain a comma must be enclosed in straight double quotation marks ("), which will not be considered part of the entity.<br />
<br />
Spaces (ASCII character 32) between the entities are recommended for readability, but not required. Example: 'John Doe, Jane Lee, "L J Smith, Jr." '<br />
<br />
The same protocol may be used within free-text attributes, but is only recommended in cases where the attribute is being populated with structured data (rather than unconstrained text).<br />
<br />
=== Free Text Formatting: Structured Text Considerations ===<br />
<br />
In some attributes, it may be desirable to use structured text to support computer parsing of human-readable content. Because netCDF files are often translated between binary and text-based encodings like ncML (e.g., by the netCDF command line tools ''nco''), such structures should tolerate changes in white space, including end-of-line characters, that may occur during translation.<br />
<br />
= Global Attributes = <br />
== Highly Recommended ==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top" id="title">title</td><br />
<td valign="top">A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide] and the [http://cfconventions.org/ CF conventions]. </td><br />
</tr><br />
<tr><br />
<td valign="top" id="summary">summary</td><br />
<td valign="top">A paragraph describing the dataset, analogous to an abstract for a paper.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="keywords">keywords</td><br />
<td valign="top">A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary ([http://gcmd.gsfc.nasa.gov/learn/keywords.html GCMD] is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute).</td><br />
</tr><br />
<tr><br />
<td valign="top" id="Conventions">Conventions</td><br />
<td valign="top">A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3'. (This attribute is described in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Conventions NetCDF Users Guide].)</td><br />
</tr><br />
</table><br />
<br />
==Recommended== <br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top" id="id">id</td><br />
<td valign="top">An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include white space characters. </td><br />
</tr><br />
<tr><br />
<td valign="top" id="naming_authority">naming_authority</td><br />
<td valign="top"> The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Example: 'edu.ucar.unidata'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="history">history</td><br />
<td valign="top">Provides an audit trail for modifications to the original data. This attribute is also in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. </td><br />
</tr><br />
<tr><br />
<td valign="top" id="source">source</td><br />
<td valign="top">The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'. <br />
</tr><br />
<tr><br />
<td valign="top" id="processing_level">processing_level</td><br />
<td valign="top">A textual description of the processing (or quality control) level of the data.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="comment">comment</td><br />
<td valign="top"> Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the [http://cfconventions.org/ CF Conventions].</td><br />
</tr><br />
<tr><br />
<td valign="top" id="acknowledgement">acknowledgement</td><br />
<td valign="top">A place to acknowledge various types of support for the project that produced this data. </td><br />
</tr><br />
<tr><br />
<td valign="top" id="license">license</td><br />
<td valign="top">Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="standard_name_vocabulary">standard_name_vocabulary</td><br />
<td valign="top"> The name and version of the controlled vocabulary from which variable standard names are taken. (Values for any standard_name attribute must come from the CF Standard Names vocabulary for the data file or product to comply with CF.) Example: 'CF Standard Name Table v27'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="date_created">date_created</td><br />
<td valign="top">The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="creator_name">creator_name</td><br />
<td valign="top">The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="creator_email">creator_email</td><br />
<td valign="top">The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="creator_url">creator_url</td><br />
<td valign="top">The URL of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="institution">institution</td><br />
<td valign="top">The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="project">project</td><br />
<td valign="top">The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="publisher_name">publisher_name</td><br />
<td valign="top">The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="publisher_email">publisher_email</td><br />
<td valign="top">The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="publisher_url">publisher_url</td><br />
<td valign="top">The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_bounds">geospatial_bounds</td><br />
<td>Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: 'POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_bounds_crs">geospatial_bounds_crs</td><br />
<td>The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: 'EPSG:4979' (the 3D WGS84 CRS), 'EPSG:4047'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_bounds_vertical_crs">geospatial_bounds_vertical_crs</td><br />
<td>The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: 'EPSG:5829' (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or 'EPSG:5703' (NAVD88 height).</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lat_min">geospatial_lat_min</td><br />
<td valign="top">Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lat_max">geospatial_lat_max</td><br />
<td valign="top">Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lon_min">geospatial_lon_min</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lon_max">geospatial_lon_max</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_vertical_min">geospatial_vertical_min</td><br />
<td valign="top">Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_vertical_max">geospatial_vertical_max</td><br />
<td valign="top">Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_vertical_positive">geospatial_vertical_positive</td><br />
<td valign="top">One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="time_coverage_start">time_coverage_start</td><br />
<td valign="top">Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="time_coverage_end">time_coverage_end</td><br />
<td valign="top">Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="time_coverage_duration">time_coverage_duration</td><br />
<td valign="top">Describes the duration of the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="time_coverage_resolution">time_coverage_resolution</td><br />
<td valign="top">Describes the targeted time period between each value in the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
</table><br />
<br />
==Suggested==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top" id="creator_type">creator_type</td><br />
<td valign="top">Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="creator_institution">creator_institution</td><br />
<td valign="top">The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="publisher_type">publisher_type</td><br />
<td valign="top">Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="publisher_institution">publisher_institution</td><br />
<td valign="top">The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="program">program</td><br />
<td valign="top">The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.<br />
</td><br />
</tr><br />
<tr><br />
<td valign="top" id="contributor_name">contributor_name</td><br />
<td valign="top">The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).</td><br />
</tr><br />
<tr><br />
<td valign="top" id="contributor_role">contributor_role</td><br />
<td valign="top">The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lat_units">geospatial_lat_units</td><br />
<td valign="top">Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed to be "degree_north"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lat_resolution">geospatial_lat_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lon_units">geospatial_lon_units</td><br />
<td valign="top">Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed to be "degree_east"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_lon_resolution">geospatial_lon_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_vertical_units">geospatial_vertical_units</td><br />
<td valign="top">Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).</td><br />
</tr><br />
<tr><br />
<td valign="top" id="geospatial_vertical_resolution">geospatial_vertical_resolution</td><br />
<td valign="top">Information about the targeted vertical spacing of points. Example: '25 meters'</td><br />
</tr><br />
<tr><br />
<td valign="top" id="date_modified">date_modified</td><br />
<td valign="top">The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="date_issued">date_issued</td><br />
<td valign="top">The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="date_metadata_modified">date_metadata_modified</td><br />
<td valign="top">The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="product_version">product_version</td><br />
<td valign="top">Version identifier of the data file or product as assigned by the data creator. For example, a new algorithm or methodology could result in a new product_version.</td><br />
<tr><br />
<td valign="top" id="keywords_vocabulary">keywords_vocabulary</td><br />
<td valign="top">If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. Example: 'GCMD:GCMD Keywords, CF:NetCDF COARDS Climate and Forecast Standard Names'.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="platform">platform</td><br />
<td valign="top">Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="platform_vocabulary">platform_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "platform" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="instrument">instrument</td><br />
<td valign="top">Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="instrument_vocabulary">instrument_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "instrument" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="cdm_data_type">cdm_data_type</td><br />
<td>The data type, as derived from Unidata's Common Data Model Scientific Data types and understood by THREDDS. (This is a THREDDS "dataType", and is different from the CF NetCDF attribute 'featureType', which indicates a Discrete Sampling Geometry file in CF.)</td><br />
</tr><br />
<tr><br />
<td valign="top" id="metadata_link">metadata_link</td><br />
<td valign="top">A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="references">references</td><br />
<td valign="top">Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.</td><br />
</tr><br />
</table><br />
<br />
=Highly Recommended Variable Attributes=<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top" id="long_name">long_name</td><br />
<td valign="top">A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="standard_name">standard_name</td><br />
<td>A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="units">units</td><br />
<td valign="top">The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top" id="coverage_content_type">coverage_content_type</td><br />
<td valign="top">An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).</td><br />
</tr><br />
</table><br />
<br />
=Deprecated Attribute=<br />
The following term and definition is still recognized, but is no longer recommended for use by ACDD.<br />
<br />
: Metadata_Convention: removed in favor of 'Conventions'<br />
<br />
= Index by Attribute Name =<br />
<table><br />
<tr><br />
<td valign="top"><br />
<ul><br />
<li>[[#acknowledgement|acknowledgement]] (Recommended)</li><br />
<li>[[#cdm_data_type|cdm_data_type]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#comment|comment]] (Recommended)</li><br />
<li>[[#contributor_name|contributor_name]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#contributor_role|contributor_role]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#Conventions|Conventions]] ('''Highly Recommended''')</li><br />
<li>[[#coverage_content_type|coverage_content_type]] ('''Highly Recommended''') [Variable]</li><br />
<li>[[#creator_email|creator_email]] (Recommended)</li><br />
<li>[[#creator_institution|creator_institution]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#creator_name|creator_name]] (Recommended)</li><br />
<li>[[#creator_type|creator_type]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#creator_url|creator_url]] (Recommended)</li><br />
<li>[[#date_created|date_created]] (Recommended)</li><br />
<li>[[#date_issued|date_issued]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#date_metadata_modified|date_metadata_modified]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#date_modified|date_modified]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#geospatial_bounds|geospatial_bounds]] (Recommended)</li><br />
<li>[[#geospatial_bounds_crs|geospatial_bounds_crs]] (Recommended)</li><br />
<li>[[#geospatial_bounds_vertical_crs|geospatial_bounds_vertical_crs]] (Recommended)</li><br />
<li>[[#geospatial_lat_max|geospatial_lat_max]] (Recommended)</li><br />
<li>[[#geospatial_lat_min|geospatial_lat_min]] (Recommended)</li><br />
<li>[[#geospatial_lat_resolution|geospatial_lat_resolution]] (<font color="gray">Suggested</font>)</li><br />
</ul><br />
</td><br />
<td valign="top"><br />
<ul> <br />
<li>[[#geospatial_lat_units|geospatial_lat_units]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#geospatial_lon_max|geospatial_lon_max]] (Recommended)</li><br />
<li>[[#geospatial_lon_min|geospatial_lon_min]] (Recommended)</li><br />
<li>[[#geospatial_lon_resolution|geospatial_lon_resolution]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#geospatial_lon_units|geospatial_lon_units]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#geospatial_vertical_max|geospatial_vertical_max]] (Recommended)</li><br />
<li>[[#geospatial_vertical_min|geospatial_vertical_min]] (Recommended)</li><br />
<li>[[#geospatial_vertical_positive|geospatial_vertical_positive]] (Recommended)</li><br />
<li>[[#geospatial_vertical_resolution|geospatial_vertical_resolution]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#geospatial_vertical_units|geospatial_vertical_units]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#history|history]] (Recommended)</li><br />
<li>[[#id|id]] (Recommended)</li><br />
<li>[[#institution|institution]] (Recommended)</li><br />
<li>[[#instrument|instrument]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#instrument_vocabulary|instrument_vocabulary]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#keywords|keywords]] ('''Highly Recommended''')</li><br />
<li>[[#keywords_vocabulary|keywords_vocabulary]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#license|license]] (Recommended)</li><br />
<li>[[#long_name|long_name]] ('''Highly Recommended''') [Variable]</li><br />
<li>[[#metadata_link|metadata_link]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#naming_authority|naming_authority]] (Recommended)</li><br />
<li>[[#platform|platform]] (<font color="gray">Suggested</font>)</li><br />
</ul><br />
</td><br />
<td valign="top"><br />
<ul><br />
<li>[[#platform_vocabulary|platform_vocabulary]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#processing_level|processing_level]] (Recommended)</li><br />
<li>[[#product_version|product_version]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#program|program]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#project|project]] (Recommended)</li><br />
<li>[[#publisher_email|publisher_email]] (Recommended)</li><br />
<li>[[#publisher_institution|publisher_institution]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#publisher_name|publisher_name]] (Recommended)</li><br />
<li>[[#publisher_type|publisher_type]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#publisher_url|publisher_url]] (Recommended)</li><br />
<li>[[#references|references]] (<font color="gray">Suggested</font>)</li><br />
<li>[[#source|source]] (Recommended)</li><br />
<li>[[#standard_name|standard_name]] ('''Highly Recommended''') [Variable]</li><br />
<li>[[#standard_name_vocabulary|standard_name_vocabulary]] (Recommended)</li><br />
<li>[[#summary|summary]] ('''Highly Recommended''')</li><br />
<li>[[#time_coverage_duration|time_coverage_duration]] (Recommended)</li><br />
<li>[[#time_coverage_end|time_coverage_end]] (Recommended)</li><br />
<li>[[#time_coverage_resolution|time_coverage_resolution]] (Recommended)</li><br />
<li>[[#time_coverage_start|time_coverage_start]] (Recommended)</li><br />
<li>[[#title|title]] ('''Highly Recommended''')</li><br />
<li>[[#units|units]] ('''Highly Recommended''') [Variable]</li><br />
</ul><br />
</td><br />
</tr><br />
</table><br />
<br />
= Conformance Test =<br />
Conformance tests are available for verson 1.1. A conformance test for this version will be linked from this page when it is available.<br />
<br />
= Additional Materials =<br />
These materials are not normative and may not be in alignment with this version of ACDD. <br />
* Mappings ACDD to other metadata dialects<br />
**[[Attribute Convention for Data Discovery (ACDD) Mappings]]-<br />
* Recommended Order of Precedence<br />
**[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
* Future Directions: Object Conventions for Data Discovery<br />
** [[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
* ISO Translation Notes<br />
** http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-3&diff=48476Attribute Convention for Data Discovery 1-32014-12-08T16:20:15Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div> <font color="red">'''PROPOSED - Ready for review'''</font><br />
= Context =<br />
<br />
== Document ==<br />
<br />
This is the Attribute Convention for Data Discovery (ACDD).<br />
<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.3.4. It is a version proposed for review by the full Documentation Cluster. This version includes attribute changes as of Adjudication meeting #3, and (in '''bold'''/<del>strikeout</del>) some minor or discussed changes since then, including at the Nov ESIP Documentation meeting. ''(Once approved, this paragraph will be replaced by 'This is version 1.3 of the ACDD; it is the latest released version.')''<br />
<br />
The page [[Attribute Convention for Data Discovery (ACDD)]] always points to the current released version of the Convention. The version number at the top of the resulting page will show the current version.<br />
<br />
See the [http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery ACDD category page] for information on the history and maintenance of this convention.<br />
<br />
=== Development ===<br />
<br />
For development versions of the ACDD, please see the page [[Attribute Convention for Data Discovery Working]].<br />
<br />
= Overview =<br />
This document describes attributes recommended for describing a NetCDF dataset to discovery systems such as Digital Libraries. THREDDS and other tools can use these attributes <del>for extracting</del> '''to extract''' metadata from datasets, and exporting to Dublin Core, DIF, ADN, FGDC, ISO 19115 and other metadata formats. This will help systems and users locate and use data efficiently.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cfconventions.org/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines three, title, history, and Conventions. CF specifies more: institution, source, references, comment, and featureType. ACDD 1.3 adopts all CF 1.6 global attributes. In a change from ACDD 1.2, we adopt the NUG recommendation to supply all conventions in the single Conventions attribute.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so <del>they are available</del>'''similar terms exist''' in many metadata standards. This [[Attribute_Convention_for_Data_Discovery_(ACDD)_Mappings]] page includes a crosswalk to THREDDS, OGC CSW, ISO 19115-2 and Rubric Categories.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<del>The netCDF metadata model is focused on providing "use metadata" for the data included in the file (or granule). Other metadata dialects (i.e.</del> '''Documents using other metadata specifications (e.g.''', ISO 19115) can provide '''additional''' information about <del>collections and more details about</del> the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Definitions: Data and Metadata ==<br />
<br />
In several ACDD attribute names or definitions, the terms 'data' and 'metadata' are used. In the context of NetCDF files, these refer specifically to the values within the file, and the attributes of the file, respectively.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize '''the data they are associated with.'''<del>their containing (parent) granules.</del> As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible '''for updating''' <del>to update</del> these attributes as part of the processing, but '''unfortunately''' some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, <del>which comprises three</del> '''including these''' roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and '''associated data.''' <del>of the granule or file data.</del> The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<!--''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''--><br />
<br />
== Attribute Content Guidance ==<br />
<br />
=== Date and Time: ISO 8601 Recommended Formats ===<br />
<br />
The ACDD specifies [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601:2004] date and time formats for its temporal attributes. ACDD strongly encourages the use of the 'extended' format date-time, in the form <br />
<tt>YYYY-MM-DDThh:mm:ss<zone></tt><br />
(although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, or ±hh). Per the standard, the shortened or basic format, which omits the - and : separators, "should be avoided in plain text."<br />
<br />
For duration attributes, again the extended form is strongly encouraged for readability:<br />
<tt>P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]</tt><br />
<br />
If for some reason the strongly encouraged formats can not be used, other ISO 8601-compatible formats are acceptable, but may not be handled by some processing software.<br />
<br />
=== Comma-Separated Lists ===<br />
<br />
Several attributes explicitly allow the entry of multiple entities as comma-separated values. The entities in such lists which contain a comma must be enclosed in straight double quotation marks ("), which will not be considered part of the entity.<br />
<br />
'''Spaces (ASCII character 32)''' <del>Blanks</del> between the entities are recommended for readability, but not required.<br />
<br />
The same protocol may be used within free-text attributes, but is only recommended in cases where the attribute is being populated with structured data (rather than unconstrained text).<br />
<br />
=== Free Text Formatting: Structured Text Considerations ===<br />
<br />
In some attributes, it may be desirable to use structured text to support computer parsing of human-readable content. Because netCDF files are often translated between binary and text-based encodings like ncML (e.g., by the netCDF command line tools ''nco''), such structures should tolerate changes in white space, including end-of-line characters, that may occur during translation.<br />
<br />
= Global Attributes = <br />
== Highly Recommended ==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">title</td><br />
<td valign="top">A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide] and the [http://cfconventions.org/ CF conventions]. </td><br />
</tr><br />
<tr><br />
<td valign="top">summary</td><br />
<td valign="top">A paragraph describing the dataset, analogous to an abstract for a paper.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords</td><br />
<td valign="top">A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary ([http://gcmd.gsfc.nasa.gov/learn/keywords.html GCMD] is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute).</td><br />
</tr><br />
<tr><br />
<td valign="top">Conventions</td><br />
<td valign="top">A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3'. (This attribute is described in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Conventions NetCDF Users Guide].)</td><br />
</tr><br />
</table><br />
<br />
==Recommended== <br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">id</td><br />
<td valign="top">An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include '''white space characters''' <del>blanks</del>. </td><br />
</tr><br />
<tr><br />
<td valign="top">naming_authority</td><br />
<td valign="top"> The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Example: 'edu.ucar.unidata'.</td><br />
</tr><br />
<tr><br />
<td valign="top">cdm_data_type</td><br />
<td>The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file—for guidance on those terms, please see the [http://www.nodc.noaa.gov/data/formats/netcdf/ NODC guidance].</td><br />
</tr><br />
<tr><br />
<td valign="top">history</td><br />
<td valign="top">Provides an audit trail for modifications to the original data. This attribute is also in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. </td><br />
</tr><br />
<tr><br />
<td valign="top">source</td><br />
<td valign="top">The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'. <br />
</tr><br />
<tr><br />
<td valign="top">processing_level</td><br />
<td valign="top">A textual description of the processing (or quality control) level of the data.</td><br />
</tr><br />
<tr><br />
<td valign="top">comment</td><br />
<td valign="top"> Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the [http://cfconventions.org/ CF Conventions].</td><br />
</tr><br />
<tr><br />
<td valign="top">acknowledgement</td><br />
<td valign="top">A place to acknowledge various types of support for the project that produced this data. </td><br />
</tr><br />
<tr><br />
<td valign="top">license</td><br />
<td valign="top">Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name_vocabulary</td><br />
<td valign="top"> The name and version of the controlled vocabulary from which variable standard names are taken. Example: 'CF Standard Name Table v27' </td><br />
</tr><br />
<tr><br />
<td valign="top">date_created</td><br />
<td valign="top">The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_name</td><br />
<td valign="top">The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_email</td><br />
<td valign="top">The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">institution</td><br />
<td valign="top">The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">project</td><br />
<td valign="top">The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_name</td><br />
<td valign="top">The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_email</td><br />
<td valign="top">The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_url</td><br />
<td valign="top">The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_bounds</td><br />
<td>'''Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))”.''' <del> Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.</del></td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_crs'''</td><br />
<td>'''The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047”.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_vertical_crs'''</td><br />
<td>'''The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: "EPSG:5829" (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or "EPSG:5703" (NAVD88 height).'''</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_min</td><br />
<td valign="top">Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_max</td><br />
<td valign="top">Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_min</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_max</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_min</td><br />
<td valign="top">Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_max</td><br />
<td valign="top">Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_positive</td><br />
<td valign="top">One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_start</td><br />
<td valign="top">Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_end</td><br />
<td valign="top">Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_duration</td><br />
<td valign="top">Describes the duration of the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_resolution</td><br />
<td valign="top">Describes the targeted time period between each value in the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
</table><br />
<br />
==Suggested==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">creator_url</td><br />
<td valign="top">The URL of the <del>of the</del> person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_type</td><br />
<td valign="top">Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_institution</td><br />
<td valign="top">The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_type</td><br />
<td valign="top">Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_institution</td><br />
<td valign="top">The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.</td><br />
</tr><br />
<tr><br />
<td valign="top">program</td><br />
<td valign="top">The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.<br />
</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_name</td><br />
<td valign="top">The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_role</td><br />
<td valign="top">The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_units</td><br />
<td valign="top">Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed to be "degree_north"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_units</td><br />
<td valign="top">Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed to be "degree_east"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_units</td><br />
<td valign="top">Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_resolution</td><br />
<td valign="top">Information about the targeted vertical spacing of points. Example: '25 meters'</td><br />
</tr><br />
<tr><br />
<td valign="top">date_modified</td><br />
<td valign="top">The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_issued</td><br />
<td valign="top">The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_metadata_modified</td><br />
<td valign="top">The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords_vocabulary</td><br />
<td valign="top">If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix <del>(e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names")</del> and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. '''Example: 'GCMD:GCMD Keywords, CF:NetCDF COARDS Climate and Forecast Standard Names'.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">platform</td><br />
<td valign="top">Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">platform_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "platform" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument</td><br />
<td valign="top">Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "instrument" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">metadata_link</td><br />
<td valign="top">A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">references</td><br />
<td valign="top">Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.</td><br />
</tr><br />
</table><br />
<br />
=Highly Recommended Variable Attributes=<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">long_name</td><br />
<td valign="top">A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name</td><br />
<td>A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">units</td><br />
<td valign="top">The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">coverage_content_type</td><br />
<td valign="top">An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).</td><br />
</tr><br />
</table><br />
<br />
=Deprecated=<br />
The following terms and definitions are still recognized, but are no longer recommended for use by ACDD.<br />
<br />
: Metadata_Convention: removed in favor of 'Conventions'<br />
<br />
= Conformance Test =<br />
Conformance tests are available for verson 1.1. A conformance test for this version will be linked from this page when it is available.<br />
<br />
= Additional Materials =<br />
These materials are not normative and may not be in alignment with this version of ACDD. <br />
* Mappings ACDD to other metadata dialects<br />
**[[Attribute Convention for Data Discovery (ACDD) Mappings]]-<br />
* Recommended Order of Precedence<br />
**[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
* Future Directions: Object Conventions for Data Discovery<br />
** [[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
* ISO Translation Notes<br />
** http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-3&diff=48475Attribute Convention for Data Discovery 1-32014-12-08T16:15:57Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div> <font color="red">'''PROPOSED - Ready for review'''</font><br />
= Context =<br />
<br />
== Document ==<br />
<br />
This is the Attribute Convention for Data Discovery (ACDD).<br />
<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.3.4. It is a version proposed for review by the full Documentation Cluster. This version includes attribute changes as of Adjudication meeting #3, and (in '''bold'''/<del>strikeout</del>) some minor or discussed changes since then, including at the Nov ESIP Documentation meeting. ''(Once approved, this paragraph will be replaced by 'This is version 1.3 of the ACDD; it is the latest released version.')''<br />
<br />
The page [[Attribute Convention for Data Discovery (ACDD)]] always points to the current released version of the Convention. The version number at the top of the resulting page will show the current version.<br />
<br />
See the [http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery ACDD category page] for information on the history and maintenance of this convention.<br />
<br />
=== Development ===<br />
<br />
For development versions of the ACDD, please see the page [[Attribute Convention for Data Discovery Working]].<br />
<br />
= Overview =<br />
This document describes attributes recommended for describing a NetCDF dataset to discovery systems such as Digital Libraries. THREDDS and other tools can use these attributes <del>for extracting</del> '''to extract''' metadata from datasets, and exporting to Dublin Core, DIF, ADN, FGDC, ISO 19115 and other metadata formats. This will help systems and users locate and use data efficiently.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cfconventions.org/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines three, title, history, and Conventions. CF specifies more: institution, source, references, comment, and featureType. ACDD 1.3 adopts all CF 1.7 global attributes. In a change from ACDD 1.2, we adopt the NUG recommendation to supply all conventions in the single Conventions attribute.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so <del>they are available</del>'''similar terms exist''' in many metadata standards. This [[Attribute_Convention_for_Data_Discovery_(ACDD)_Mappings]] page includes a crosswalk to THREDDS, OGC CSW, ISO 19115-2 and Rubric Categories.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<del>The netCDF metadata model is focused on providing "use metadata" for the data included in the file (or granule). Other metadata dialects (i.e.</del> '''Documents using other metadata specifications (e.g.''', ISO 19115) can provide '''additional''' information about <del>collections and more details about</del> the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Definitions: Data and Metadata ==<br />
<br />
In several ACDD attribute names or definitions, the terms 'data' and 'metadata' are used. In the context of NetCDF files, these refer specifically to the values within the file, and the attributes of the file, respectively.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize '''the data they are associated with.'''<del>their containing (parent) granules.</del> As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible '''for updating''' <del>to update</del> these attributes as part of the processing, but '''unfortunately''' some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, <del>which comprises three</del> '''including these''' roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and '''associated data.''' <del>of the granule or file data.</del> The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<!--''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''--><br />
<br />
== Attribute Content Guidance ==<br />
<br />
=== Date and Time: ISO 8601 Recommended Formats ===<br />
<br />
The ACDD specifies [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601:2004] date and time formats for its temporal attributes. ACDD strongly encourages the use of the 'extended' format date-time, in the form <br />
<tt>YYYY-MM-DDThh:mm:ss<zone></tt><br />
(although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, or ±hh). Per the standard, the shortened or basic format, which omits the - and : separators, "should be avoided in plain text."<br />
<br />
For duration attributes, again the extended form is strongly encouraged for readability:<br />
<tt>P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]</tt><br />
<br />
If for some reason the strongly encouraged formats can not be used, other ISO 8601-compatible formats are acceptable, but may not be handled by some processing software.<br />
<br />
=== Comma-Separated Lists ===<br />
<br />
Several attributes explicitly allow the entry of multiple entities as comma-separated values. The entities in such lists which contain a comma must be enclosed in straight double quotation marks ("), which will not be considered part of the entity.<br />
<br />
'''Spaces (ASCII character 32)''' <del>Blanks</del> between the entities are recommended for readability, but not required.<br />
<br />
The same protocol may be used within free-text attributes, but is only recommended in cases where the attribute is being populated with structured data (rather than unconstrained text).<br />
<br />
=== Free Text Formatting: Structured Text Considerations ===<br />
<br />
In some attributes, it may be desirable to use structured text to support computer parsing of human-readable content. Because netCDF files are often translated between binary and text-based encodings like ncML (e.g., by the netCDF command line tools ''nco''), such structures should tolerate changes in white space, including end-of-line characters, that may occur during translation.<br />
<br />
= Global Attributes = <br />
== Highly Recommended ==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">title</td><br />
<td valign="top">A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide] and the [http://cfconventions.org/ CF conventions]. </td><br />
</tr><br />
<tr><br />
<td valign="top">summary</td><br />
<td valign="top">A paragraph describing the dataset, analogous to an abstract for a paper.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords</td><br />
<td valign="top">A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary ([http://gcmd.gsfc.nasa.gov/learn/keywords.html GCMD] is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute).</td><br />
</tr><br />
<tr><br />
<td valign="top">Conventions</td><br />
<td valign="top">A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3'. (This attribute is described in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Conventions NetCDF Users Guide].)</td><br />
</tr><br />
</table><br />
<br />
==Recommended== <br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">id</td><br />
<td valign="top">An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include '''white space characters''' <del>blanks</del>. </td><br />
</tr><br />
<tr><br />
<td valign="top">naming_authority</td><br />
<td valign="top"> The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Example: 'edu.ucar.unidata'.</td><br />
</tr><br />
<tr><br />
<td valign="top">cdm_data_type</td><br />
<td>The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file—for guidance on those terms, please see the [http://www.nodc.noaa.gov/data/formats/netcdf/ NODC guidance].</td><br />
</tr><br />
<tr><br />
<td valign="top">history</td><br />
<td valign="top">Provides an audit trail for modifications to the original data. This attribute is also in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. </td><br />
</tr><br />
<tr><br />
<td valign="top">source</td><br />
<td valign="top">The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'. <br />
</tr><br />
<tr><br />
<td valign="top">processing_level</td><br />
<td valign="top">A textual description of the processing (or quality control) level of the data.</td><br />
</tr><br />
<tr><br />
<td valign="top">comment</td><br />
<td valign="top"> Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the [http://cfconventions.org/ CF Conventions].</td><br />
</tr><br />
<tr><br />
<td valign="top">acknowledgement</td><br />
<td valign="top">A place to acknowledge various types of support for the project that produced this data. </td><br />
</tr><br />
<tr><br />
<td valign="top">license</td><br />
<td valign="top">Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name_vocabulary</td><br />
<td valign="top"> The name and version of the controlled vocabulary from which variable standard names are taken. Example: 'CF Standard Name Table v27' </td><br />
</tr><br />
<tr><br />
<td valign="top">date_created</td><br />
<td valign="top">The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_name</td><br />
<td valign="top">The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_email</td><br />
<td valign="top">The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">institution</td><br />
<td valign="top">The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">project</td><br />
<td valign="top">The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_name</td><br />
<td valign="top">The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_email</td><br />
<td valign="top">The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_url</td><br />
<td valign="top">The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_bounds</td><br />
<td>'''Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))”.''' <del> Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.</del></td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_crs'''</td><br />
<td>'''The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047”.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_vertical_crs'''</td><br />
<td>'''The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: "EPSG:5829" (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or "EPSG:5703" (NAVD88 height).'''</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_min</td><br />
<td valign="top">Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_max</td><br />
<td valign="top">Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_min</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_max</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_min</td><br />
<td valign="top">Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_max</td><br />
<td valign="top">Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_positive</td><br />
<td valign="top">One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_start</td><br />
<td valign="top">Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_end</td><br />
<td valign="top">Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_duration</td><br />
<td valign="top">Describes the duration of the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_resolution</td><br />
<td valign="top">Describes the targeted time period between each value in the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
</table><br />
<br />
==Suggested==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">creator_url</td><br />
<td valign="top">The URL of the <del>of the</del> person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_type</td><br />
<td valign="top">Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_institution</td><br />
<td valign="top">The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_type</td><br />
<td valign="top">Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_institution</td><br />
<td valign="top">The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.</td><br />
</tr><br />
<tr><br />
<td valign="top">program</td><br />
<td valign="top">The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.<br />
</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_name</td><br />
<td valign="top">The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_role</td><br />
<td valign="top">The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_units</td><br />
<td valign="top">Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed to be "degree_north"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_units</td><br />
<td valign="top">Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed to be "degree_east"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_units</td><br />
<td valign="top">Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_resolution</td><br />
<td valign="top">Information about the targeted vertical spacing of points. Example: '25 meters'</td><br />
</tr><br />
<tr><br />
<td valign="top">date_modified</td><br />
<td valign="top">The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_issued</td><br />
<td valign="top">The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_metadata_modified</td><br />
<td valign="top">The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords_vocabulary</td><br />
<td valign="top">If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix <del>(e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names")</del> and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. '''Example: 'GCMD:GCMD Keywords, CF:NetCDF COARDS Climate and Forecast Standard Names'.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">platform</td><br />
<td valign="top">Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">platform_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "platform" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument</td><br />
<td valign="top">Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "instrument" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">metadata_link</td><br />
<td valign="top">A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">references</td><br />
<td valign="top">Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.</td><br />
</tr><br />
</table><br />
<br />
=Highly Recommended Variable Attributes=<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">long_name</td><br />
<td valign="top">A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name</td><br />
<td>A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">units</td><br />
<td valign="top">The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">coverage_content_type</td><br />
<td valign="top">An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).</td><br />
</tr><br />
</table><br />
<br />
=Deprecated=<br />
The following terms and definitions are still recognized, but are no longer recommended for use by ACDD.<br />
<br />
: Metadata_Convention: removed in favor of 'Conventions'<br />
<br />
= Conformance Test =<br />
Conformance tests are available for verson 1.1. A conformance test for this version will be linked from this page when it is available.<br />
<br />
= Additional Materials =<br />
These materials are not normative and may not be in alignment with this version of ACDD. <br />
* Mappings ACDD to other metadata dialects<br />
**[[Attribute Convention for Data Discovery (ACDD) Mappings]]-<br />
* Recommended Order of Precedence<br />
**[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
* Future Directions: Object Conventions for Data Discovery<br />
** [[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
* ISO Translation Notes<br />
** http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-3&diff=48474Attribute Convention for Data Discovery 1-32014-12-08T15:58:45Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div> <font color="red">'''PROPOSED - Ready for review'''</font><br />
= Context =<br />
<br />
== Document ==<br />
<br />
This is the Attribute Convention for Data Discovery (ACDD).<br />
<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.3.4. It is a version proposed for review by the full Documentation Cluster. This version includes attribute changes as of Adjudication meeting #3, and (in '''bold'''/<del>strikeout</del>) some minor or discussed changes since then, including at the Nov ESIP Documentation meeting. ''(Once approved, this paragraph will be replaced by 'This is version 1.3 of the ACDD; it is the latest released version.')''<br />
<br />
The page [[Attribute Convention for Data Discovery (ACDD)]] always points to the current released version of the Convention. The version number at the top of the resulting page will show the current version.<br />
<br />
See the [http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery ACDD category page] for information on the history and maintenance of this convention.<br />
<br />
=== Development ===<br />
<br />
For development versions of the ACDD, please see the page [[Attribute Convention for Data Discovery Working]].<br />
<br />
= Overview =<br />
This document describes attributes recommended for describing a NetCDF dataset to discovery systems such as Digital Libraries. THREDDS and other tools can use these attributes <del>for extracting</del> '''to extract''' metadata from datasets, and exporting to Dublin Core, DIF, ADN, FGDC, ISO 19115 and other metadata formats. This will help systems and users locate and use data efficiently.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cfconventions.org/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history. CF specifies more: institution, source, references, comment, featureType, and Conventions. ACDD 1.3 adopts all CF 1.6 global attributes. We modify the syntax of the 'Conventions' attribute; we adopt the NUG recommendation to supply all conventions in a single attribute. This change has been approved by the CF Conventions Committee and will be part of CF 1.7, which is not yet published.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so <del>they are available</del>'''similar terms exist''' in many metadata standards. This [[Attribute_Convention_for_Data_Discovery_(ACDD)_Mappings]] page includes a crosswalk to THREDDS, OGC CSW, ISO 19115-2 and Rubric Categories.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<del>The netCDF metadata model is focused on providing "use metadata" for the data included in the file (or granule). Other metadata dialects (i.e.</del> '''Documents using other metadata specifications (e.g.''', ISO 19115) can provide '''additional''' information about <del>collections and more details about</del> the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Definitions: Data and Metadata ==<br />
<br />
In several ACDD attribute names or definitions, the terms 'data' and 'metadata' are used. In the context of NetCDF files, these refer specifically to the values within the file, and the attributes of the file, respectively.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize '''the data they are associated with.'''<del>their containing (parent) granules.</del> As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible '''for updating''' <del>to update</del> these attributes as part of the processing, but '''unfortunately''' some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, <del>which comprises three</del> '''including these''' roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and '''associated data.''' <del>of the granule or file data.</del> The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<!--''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''--><br />
<br />
== Attribute Content Guidance ==<br />
<br />
=== Date and Time: ISO 8601 Recommended Formats ===<br />
<br />
The ACDD specifies [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601:2004] date and time formats for its temporal attributes. ACDD strongly encourages the use of the 'extended' format date-time, in the form <br />
<tt>YYYY-MM-DDThh:mm:ss<zone></tt><br />
(although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, or ±hh). Per the standard, the shortened or basic format, which omits the - and : separators, "should be avoided in plain text."<br />
<br />
For duration attributes, again the extended form is strongly encouraged for readability:<br />
<tt>P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]</tt><br />
<br />
If for some reason the strongly encouraged formats can not be used, other ISO 8601-compatible formats are acceptable, but may not be handled by some processing software.<br />
<br />
=== Comma-Separated Lists ===<br />
<br />
Several attributes explicitly allow the entry of multiple entities as comma-separated values. The entities in such lists which contain a comma must be enclosed in straight double quotation marks ("), which will not be considered part of the entity.<br />
<br />
'''Spaces (ASCII character 32)''' <del>Blanks</del> between the entities are recommended for readability, but not required.<br />
<br />
The same protocol may be used within free-text attributes, but is only recommended in cases where the attribute is being populated with structured data (rather than unconstrained text).<br />
<br />
=== Free Text Formatting: Structured Text Considerations ===<br />
<br />
In some attributes, it may be desirable to use structured text to support computer parsing of human-readable content. Because netCDF files are often translated between binary and text-based encodings like ncML (e.g., by the netCDF command line tools ''nco''), such structures should tolerate changes in white space, including end-of-line characters, that may occur during translation.<br />
<br />
= Global Attributes = <br />
== Highly Recommended ==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">title</td><br />
<td valign="top">A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide] and the [http://cfconventions.org/ CF conventions]. </td><br />
</tr><br />
<tr><br />
<td valign="top">summary</td><br />
<td valign="top">A paragraph describing the dataset, analogous to an abstract for a paper.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords</td><br />
<td valign="top">A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary ([http://gcmd.gsfc.nasa.gov/learn/keywords.html GCMD] is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute).</td><br />
</tr><br />
<tr><br />
<td valign="top">Conventions</td><br />
<td valign="top">A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3'. (This attribute is described in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Conventions NetCDF Users Guide].)</td><br />
</tr><br />
</table><br />
<br />
==Recommended== <br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">id</td><br />
<td valign="top">An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include '''white space characters''' <del>blanks</del>. </td><br />
</tr><br />
<tr><br />
<td valign="top">naming_authority</td><br />
<td valign="top"> The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Example: 'edu.ucar.unidata'.</td><br />
</tr><br />
<tr><br />
<td valign="top">cdm_data_type</td><br />
<td>The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file—for guidance on those terms, please see the [http://www.nodc.noaa.gov/data/formats/netcdf/ NODC guidance].</td><br />
</tr><br />
<tr><br />
<td valign="top">history</td><br />
<td valign="top">Provides an audit trail for modifications to the original data. This attribute is also in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. </td><br />
</tr><br />
<tr><br />
<td valign="top">source</td><br />
<td valign="top">The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'. <br />
</tr><br />
<tr><br />
<td valign="top">processing_level</td><br />
<td valign="top">A textual description of the processing (or quality control) level of the data.</td><br />
</tr><br />
<tr><br />
<td valign="top">comment</td><br />
<td valign="top"> Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the [http://cfconventions.org/ CF Conventions].</td><br />
</tr><br />
<tr><br />
<td valign="top">acknowledgement</td><br />
<td valign="top">A place to acknowledge various types of support for the project that produced this data. </td><br />
</tr><br />
<tr><br />
<td valign="top">license</td><br />
<td valign="top">Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name_vocabulary</td><br />
<td valign="top"> The name and version of the controlled vocabulary from which variable standard names are taken. Example: 'CF Standard Name Table v27' </td><br />
</tr><br />
<tr><br />
<td valign="top">date_created</td><br />
<td valign="top">The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_name</td><br />
<td valign="top">The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_email</td><br />
<td valign="top">The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">institution</td><br />
<td valign="top">The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">project</td><br />
<td valign="top">The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_name</td><br />
<td valign="top">The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_email</td><br />
<td valign="top">The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_url</td><br />
<td valign="top">The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_bounds</td><br />
<td>'''Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))”.''' <del> Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.</del></td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_crs'''</td><br />
<td>'''The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047”.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_vertical_crs'''</td><br />
<td>'''The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: "EPSG:5829" (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or "EPSG:5703" (NAVD88 height).'''</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_min</td><br />
<td valign="top">Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_max</td><br />
<td valign="top">Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_min</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_max</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_min</td><br />
<td valign="top">Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_max</td><br />
<td valign="top">Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_positive</td><br />
<td valign="top">One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_start</td><br />
<td valign="top">Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_end</td><br />
<td valign="top">Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_duration</td><br />
<td valign="top">Describes the duration of the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_resolution</td><br />
<td valign="top">Describes the targeted time period between each value in the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
</table><br />
<br />
==Suggested==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">creator_url</td><br />
<td valign="top">The URL of the <del>of the</del> person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_type</td><br />
<td valign="top">Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_institution</td><br />
<td valign="top">The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_type</td><br />
<td valign="top">Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_institution</td><br />
<td valign="top">The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.</td><br />
</tr><br />
<tr><br />
<td valign="top">program</td><br />
<td valign="top">The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.<br />
</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_name</td><br />
<td valign="top">The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_role</td><br />
<td valign="top">The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_units</td><br />
<td valign="top">Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed to be "degree_north"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_units</td><br />
<td valign="top">Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed to be "degree_east"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_units</td><br />
<td valign="top">Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_resolution</td><br />
<td valign="top">Information about the targeted vertical spacing of points. Example: '25 meters'</td><br />
</tr><br />
<tr><br />
<td valign="top">date_modified</td><br />
<td valign="top">The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_issued</td><br />
<td valign="top">The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_metadata_modified</td><br />
<td valign="top">The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords_vocabulary</td><br />
<td valign="top">If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix <del>(e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names")</del> and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. '''Example: 'GCMD:GCMD Keywords, CF:NetCDF COARDS Climate and Forecast Standard Names'.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">platform</td><br />
<td valign="top">Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">platform_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "platform" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument</td><br />
<td valign="top">Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "instrument" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">metadata_link</td><br />
<td valign="top">A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">references</td><br />
<td valign="top">Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.</td><br />
</tr><br />
</table><br />
<br />
=Highly Recommended Variable Attributes=<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">long_name</td><br />
<td valign="top">A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name</td><br />
<td>A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">units</td><br />
<td valign="top">The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">coverage_content_type</td><br />
<td valign="top">An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).</td><br />
</tr><br />
</table><br />
<br />
=Deprecated=<br />
The following terms and definitions are still recognized, but are no longer recommended for use by ACDD.<br />
<br />
: Metadata_Convention: removed in favor of 'Conventions'<br />
<br />
= Conformance Test =<br />
Conformance tests are available for verson 1.1. A conformance test for this version will be linked from this page when it is available.<br />
<br />
= Additional Materials =<br />
These materials are not normative and may not be in alignment with this version of ACDD. <br />
* Mappings ACDD to other metadata dialects<br />
**[[Attribute Convention for Data Discovery (ACDD) Mappings]]-<br />
* Recommended Order of Precedence<br />
**[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
* Future Directions: Object Conventions for Data Discovery<br />
** [[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
* ISO Translation Notes<br />
** http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-3&diff=48473Attribute Convention for Data Discovery 1-32014-12-08T15:58:21Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div> <font color="red">'''PROPOSED - Ready for review'''</font><br />
= Context =<br />
<br />
== Document ==<br />
<br />
This is the Attribute Convention for Data Discovery (ACDD).<br />
<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.3.4. It is a version proposed for review by the full Documentation Cluster. This version includes attribute changes as of Adjudication meeting #3, and (in '''bold'''/<del>strikeout</del>) some minor or discussed changes since then, including at the Nov ESIP Documentation meeting. ''(Once approved, this paragraph will be replaced by 'This is version 1.3 of the ACDD; it is the latest released version.')''<br />
<br />
The page [[Attribute Convention for Data Discovery (ACDD)]] always points to the current released version of the Convention. The version number at the top of the resulting page will show the current version.<br />
<br />
See the [http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery ACDD category page] for information on the history and maintenance of this convention.<br />
<br />
=== Development ===<br />
<br />
For development versions of the ACDD, please see the page [[Attribute Convention for Data Discovery Working]].<br />
<br />
= Overview =<br />
This document describes attributes recommended for describing a NetCDF dataset to discovery systems such as Digital Libraries. THREDDS and other tools can use these attributes <del>for extracting</del> '''to extract''' metadata from datasets, and exporting to Dublin Core, DIF, ADN, FGDC, ISO 19115 and other metadata formats. This will help systems and users locate and use data efficiently.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cfconventions.org/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies more: institution, source, references, comment, featureType, and Conventions. ACDD 1.3 adopts all CF 1.6 global attributes. We modify the syntax of the 'Conventions' attribute; we adopt the NUG recommendation to supply all conventions in a single attribute. This change has been approved by the CF Conventions Committee and will be part of CF 1.7, which is not yet published.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so <del>they are available</del>'''similar terms exist''' in many metadata standards. This [[Attribute_Convention_for_Data_Discovery_(ACDD)_Mappings]] page includes a crosswalk to THREDDS, OGC CSW, ISO 19115-2 and Rubric Categories.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<del>The netCDF metadata model is focused on providing "use metadata" for the data included in the file (or granule). Other metadata dialects (i.e.</del> '''Documents using other metadata specifications (e.g.''', ISO 19115) can provide '''additional''' information about <del>collections and more details about</del> the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Definitions: Data and Metadata ==<br />
<br />
In several ACDD attribute names or definitions, the terms 'data' and 'metadata' are used. In the context of NetCDF files, these refer specifically to the values within the file, and the attributes of the file, respectively.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize '''the data they are associated with.'''<del>their containing (parent) granules.</del> As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible '''for updating''' <del>to update</del> these attributes as part of the processing, but '''unfortunately''' some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, <del>which comprises three</del> '''including these''' roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and '''associated data.''' <del>of the granule or file data.</del> The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<!--''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''--><br />
<br />
== Attribute Content Guidance ==<br />
<br />
=== Date and Time: ISO 8601 Recommended Formats ===<br />
<br />
The ACDD specifies [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601:2004] date and time formats for its temporal attributes. ACDD strongly encourages the use of the 'extended' format date-time, in the form <br />
<tt>YYYY-MM-DDThh:mm:ss<zone></tt><br />
(although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, or ±hh). Per the standard, the shortened or basic format, which omits the - and : separators, "should be avoided in plain text."<br />
<br />
For duration attributes, again the extended form is strongly encouraged for readability:<br />
<tt>P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]</tt><br />
<br />
If for some reason the strongly encouraged formats can not be used, other ISO 8601-compatible formats are acceptable, but may not be handled by some processing software.<br />
<br />
=== Comma-Separated Lists ===<br />
<br />
Several attributes explicitly allow the entry of multiple entities as comma-separated values. The entities in such lists which contain a comma must be enclosed in straight double quotation marks ("), which will not be considered part of the entity.<br />
<br />
'''Spaces (ASCII character 32)''' <del>Blanks</del> between the entities are recommended for readability, but not required.<br />
<br />
The same protocol may be used within free-text attributes, but is only recommended in cases where the attribute is being populated with structured data (rather than unconstrained text).<br />
<br />
=== Free Text Formatting: Structured Text Considerations ===<br />
<br />
In some attributes, it may be desirable to use structured text to support computer parsing of human-readable content. Because netCDF files are often translated between binary and text-based encodings like ncML (e.g., by the netCDF command line tools ''nco''), such structures should tolerate changes in white space, including end-of-line characters, that may occur during translation.<br />
<br />
= Global Attributes = <br />
== Highly Recommended ==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">title</td><br />
<td valign="top">A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is also recommended by the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide] and the [http://cfconventions.org/ CF conventions]. </td><br />
</tr><br />
<tr><br />
<td valign="top">summary</td><br />
<td valign="top">A paragraph describing the dataset, analogous to an abstract for a paper.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords</td><br />
<td valign="top">A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary ([http://gcmd.gsfc.nasa.gov/learn/keywords.html GCMD] is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute).</td><br />
</tr><br />
<tr><br />
<td valign="top">Conventions</td><br />
<td valign="top">A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3'. (This attribute is described in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Conventions NetCDF Users Guide].)</td><br />
</tr><br />
</table><br />
<br />
==Recommended== <br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">id</td><br />
<td valign="top">An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include '''white space characters''' <del>blanks</del>. </td><br />
</tr><br />
<tr><br />
<td valign="top">naming_authority</td><br />
<td valign="top"> The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Example: 'edu.ucar.unidata'.</td><br />
</tr><br />
<tr><br />
<td valign="top">cdm_data_type</td><br />
<td>The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file—for guidance on those terms, please see the [http://www.nodc.noaa.gov/data/formats/netcdf/ NODC guidance].</td><br />
</tr><br />
<tr><br />
<td valign="top">history</td><br />
<td valign="top">Provides an audit trail for modifications to the original data. This attribute is also in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NetCDF Users Guide]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. </td><br />
</tr><br />
<tr><br />
<td valign="top">source</td><br />
<td valign="top">The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'. <br />
</tr><br />
<tr><br />
<td valign="top">processing_level</td><br />
<td valign="top">A textual description of the processing (or quality control) level of the data.</td><br />
</tr><br />
<tr><br />
<td valign="top">comment</td><br />
<td valign="top"> Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the [http://cfconventions.org/ CF Conventions].</td><br />
</tr><br />
<tr><br />
<td valign="top">acknowledgement</td><br />
<td valign="top">A place to acknowledge various types of support for the project that produced this data. </td><br />
</tr><br />
<tr><br />
<td valign="top">license</td><br />
<td valign="top">Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name_vocabulary</td><br />
<td valign="top"> The name and version of the controlled vocabulary from which variable standard names are taken. Example: 'CF Standard Name Table v27' </td><br />
</tr><br />
<tr><br />
<td valign="top">date_created</td><br />
<td valign="top">The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended, as described in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_name</td><br />
<td valign="top">The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_email</td><br />
<td valign="top">The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">institution</td><br />
<td valign="top">The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">project</td><br />
<td valign="top">The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_name</td><br />
<td valign="top">The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_email</td><br />
<td valign="top">The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_url</td><br />
<td valign="top">The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_bounds</td><br />
<td>'''Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the [-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))”.''' <del> Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.</del></td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_crs'''</td><br />
<td>'''The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047”.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">'''geospatial_bounds_vertical_crs'''</td><br />
<td>'''The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: "EPSG:5829" (instantaneous height above sea level), "EPSG:5831" (instantaneous depth below sea level), or "EPSG:5703" (NAVD88 height).'''</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_min</td><br />
<td valign="top">Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_max</td><br />
<td valign="top">Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_min</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_max</td><br />
<td valign="top">Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_min</td><br />
<td valign="top">Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_max</td><br />
<td valign="top">Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_positive</td><br />
<td valign="top">One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_start</td><br />
<td valign="top">Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_end</td><br />
<td valign="top">Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_duration</td><br />
<td valign="top">Describes the duration of the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">time_coverage_resolution</td><br />
<td valign="top">Describes the targeted time period between each value in the data set. Use ISO 8601:2004 duration format, preferably the extended format as recommended in the Attribute Content Guidance section.</td><br />
</tr><br />
</table><br />
<br />
==Suggested==<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">creator_url</td><br />
<td valign="top">The URL of the <del>of the</del> person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_type</td><br />
<td valign="top">Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">creator_institution</td><br />
<td valign="top">The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_type</td><br />
<td valign="top">Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.</td><br />
</tr><br />
<tr><br />
<td valign="top">publisher_institution</td><br />
<td valign="top">The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.</td><br />
</tr><br />
<tr><br />
<td valign="top">program</td><br />
<td valign="top">The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.<br />
</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_name</td><br />
<td valign="top">The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).</td><br />
</tr><br />
<tr><br />
<td valign="top">contributor_role</td><br />
<td valign="top">The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_units</td><br />
<td valign="top">Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed to be "degree_north"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lat_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_units</td><br />
<td valign="top">Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed to be "degree_east"; other options from udunits may be specified instead.</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_lon_resolution</td><br />
<td valign="top">Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_units</td><br />
<td valign="top">Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level).</td><br />
</tr><br />
<tr><br />
<td valign="top">geospatial_vertical_resolution</td><br />
<td valign="top">Information about the targeted vertical spacing of points. Example: '25 meters'</td><br />
</tr><br />
<tr><br />
<td valign="top">date_modified</td><br />
<td valign="top">The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_issued</td><br />
<td valign="top">The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">date_metadata_modified</td><br />
<td valign="top">The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended, as described in the Attributes Content Guidance section.</td><br />
</tr><br />
<tr><br />
<td valign="top">keywords_vocabulary</td><br />
<td valign="top">If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix <del>(e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names")</del> and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. '''Example: 'GCMD:GCMD Keywords, CF:NetCDF COARDS Climate and Forecast Standard Names'.'''</td><br />
</tr><br />
<tr><br />
<td valign="top">platform</td><br />
<td valign="top">Name of the platform(s) that supported the sensor data used to create this data set or product. Platforms can be of any type, including satellite, ship, station, aircraft or other. Indicate controlled vocabulary used in platform_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">platform_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "platform" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument</td><br />
<td valign="top">Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.</td><br />
</tr><br />
<tr><br />
<td valign="top">instrument_vocabulary</td><br />
<td valign="top">Controlled vocabulary for the names used in the "instrument" attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">metadata_link</td><br />
<td valign="top">A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute.</td><br />
</tr><br />
<tr><br />
<td valign="top">references</td><br />
<td valign="top">Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions.</td><br />
</tr><br />
</table><br />
<br />
=Highly Recommended Variable Attributes=<br />
<table width="95%" border="1" cellpadding="2" cellspacing="2"><br />
<tr><br />
<th valign="top" width="200px">Attribute</th><br />
<th valign="top">Description</th><br />
</tr><br />
<tr><br />
<td valign="top">long_name</td><br />
<td valign="top">A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">standard_name</td><br />
<td>A long descriptive name for the variable taken from a controlled vocabulary of variable names. We recommend using the CF convention and the variable names from the CF standard name table. This attribute is recommended by the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">units</td><br />
<td valign="top">The units of the variable's data values. This attribute value should be a valid udunits string. The "units" attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention.</td><br />
</tr><br />
<tr><br />
<td valign="top">coverage_content_type</td><br />
<td valign="top">An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).</td><br />
</tr><br />
</table><br />
<br />
=Deprecated=<br />
The following terms and definitions are still recognized, but are no longer recommended for use by ACDD.<br />
<br />
: Metadata_Convention: removed in favor of 'Conventions'<br />
<br />
= Conformance Test =<br />
Conformance tests are available for verson 1.1. A conformance test for this version will be linked from this page when it is available.<br />
<br />
= Additional Materials =<br />
These materials are not normative and may not be in alignment with this version of ACDD. <br />
* Mappings ACDD to other metadata dialects<br />
**[[Attribute Convention for Data Discovery (ACDD) Mappings]]-<br />
* Recommended Order of Precedence<br />
**[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
* Future Directions: Object Conventions for Data Discovery<br />
** [[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
* ISO Translation Notes<br />
** http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46970Talk:Attribute Convention for Data Discovery 1-2 Working2014-06-03T12:26:44Z<p>NanGalbraith: /* Re: Feature Types (cdm and otherwise) -- NanGalbraith (talk) 13:15, 9 September 2013 (MDT) */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|-<br />
| 11 || geospatial_vertical_min/max || The current description seems to require the values to represent the distance from earth's center || || In the vertical_positive attribute this is more clear (use same reference datum as your vertical coordinate variable uses) || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates (Nan Galbraith notes: creator might be replaced by a less ambiguous term (OceanSITES is going with principal_investigator as the data 'owner' at this point) What if there is no principal investigator, is this an institution instead of a person?.<br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
====Re: Attributes Discussed and Resolved -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 14:49, 17 February 2014 (MST)====<br />
<br />
:: Replace this text with your reply<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations for the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46953Attribute Convention for Data Discovery 1-2 Working2014-06-02T14:44:52Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD 1.2 adopts all CF 1.6 global attributes with the exception of 'institution'; we specify 'creator_institution' and 'publisher_institution', to provide more provenance information. We also modify the syntax of the 'Conventions' attribute; we adopt the NUG recommendation to supply all conventions in a single attribute. This change has been approved by the CF Conventions Committee and will be part of CF 1.7, which is not yet published.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] page includes also includes a crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize their containing (parent) granules. As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible to update these attributes as part of the processing, but some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, which comprises three roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and data of the granule or file. The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<br />
''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. For files that comply with this version of ACDD, include the term ACDD-1.2. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. This attribute is defined in the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. <br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
[[Attribute Convention for Data Discovery (ACDD) Mappings]]<br />
<br />
== Recommended Order of Precedence ==<br />
[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
[[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46943Attribute Convention for Data Discovery 1-2 Working2014-05-29T15:33:45Z<p>NanGalbraith: /* Maintenance of Metadata in Derived Products */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD 1.2 adopts all CF 1.6 global attributes with the exception of 'institution'; we specify 'creator_institution' and 'publisher_institution', to provide more provenance information. We also modify the syntax of the 'Conventions' attribute; we adopt the NUG recommendation to supply all conventions in a single attribute. This change has been approved by the CF Conventions Committee and will be part of CF 1.7, which is not yet published.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] page includes also includes a crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
== Maintenance of Metadata ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize their containing (parent) granules. As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible to update these attributes as part of the processing, but some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, which comprises three roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and data of the granule or file. The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<br />
''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. For files that comply with this version of ACDD, include the term ACDD-1.2. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
[[Attribute Convention for Data Discovery (ACDD) Mappings]]<br />
<br />
== Recommended Order of Precedence ==<br />
[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
[[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46942Attribute Convention for Data Discovery 1-2 Working2014-05-29T15:28:08Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD 1.2 adopts all CF 1.6 global attributes with the exception of 'institution'; we specify 'creator_institution' and 'publisher_institution', to provide more provenance information. We also modify the syntax of the 'Conventions' attribute; we adopt the NUG recommendation to supply all conventions in a single attribute. This change has been approved by the CF Conventions Committee and will be part of CF 1.7, which is not yet published.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] page includes also includes a crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
== Maintenance of Metadata in Derived Products ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize their containing (parent) granules. As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible to update these attributes as part of the processing, but some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, which comprises three roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and data of the granule or file. The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<br />
''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. For files that comply with this version of ACDD, include the term ACDD-1.2. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
[[Attribute Convention for Data Discovery (ACDD) Mappings]]<br />
<br />
== Recommended Order of Precedence ==<br />
[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
[[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46941Attribute Convention for Data Discovery 1-2 Working2014-05-29T14:58:08Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provides more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] page includes also includes a crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
== Maintenance of Metadata in Derived Products ==<br />
<br />
ACDD attributes, like all NetCDF attributes, characterize their containing (parent) granules. As NetCDF data are processed (e.g., through subsetting or other algorithms), these characteristics can be altered. The software or user processor is responsible to update these attributes as part of the processing, but some software processes and user practices leave them unchanged. This affects both consumers and producers of these files, which comprises three roles: <br />
* developers of software tools that process NetCDF files; <br />
* users that create new NetCDF files from existing ones; and <br />
* end users of NetCDF files.<br />
<br />
NetCDF file ''creators'' (the first two roles) should ensure that the attributes of output files accurately represent those files, and specifically should not "pass through" any source attribute in unaltered form, unless it is known to remain accurate. NetCDF file ''users'' (all three roles) should verify critical attribute values, and understand how the source data and metadata were generated, to be confident the source metadata is current. <br />
<br />
The ACDD geospatiotemporal attributes present a special case, as this information is already fully defined by the CF coordinate variables (the redundant attributes are recommended to simplify access). Errors in these attributes will create an inconsistency between the metadata and data of the granule or file. The risk of these 'inconsistency errors' is highest for files that are aggregated into longer or larger products, or subset into shorter or smaller products, such as files from numerical forecast models and gridded satellite observations. For this reason, some providers of those data types may choose to omit the ACDD geospatiotemporal attributes from their files. If the ACDD geospatiotemporal attributes are present, checking them against the CF coordinate variables can serve as a partial test of the metadata's validity.<br />
<br />
''{(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.}''<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. For files that comply with this version of ACDD, include the term ACDD-1.2. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
[[Attribute Convention for Data Discovery (ACDD) Mappings]]<br />
<br />
== Recommended Order of Precedence ==<br />
[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
[[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46832Attribute Convention for Data Discovery 1-2 Working2014-05-15T13:27:14Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] page includes also includes a crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
== Maintenance of Metadata in Derived Products ==<br />
<br />
ACDD attributes describe the granules that they are contained in. As data are processed (e.g., through subsetting or other processes), these characteristics can change. It is the responsibility of the processor to update these attributes as part of the processing. <br />
That said, some software processes and user practices modify the data without appropriately updating the metadata attributes. Given this reality, users are encouraged to verify critical attribute values, and understand how the data were processed, to be confident you are not using 'stale' metadata.<br />
<br />
(Not for inclusion in final draft) As a working tool, the page [[NetCDF Utilities Metadata Handling]] has been created to identify the state of play for how tools handle metadata attributes when processing files.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. For files that comply with this version of ACDD, include the term ACDD-1.2. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
[[Attribute Convention for Data Discovery (ACDD) Mappings]]<br />
<br />
== Recommended Order of Precedence ==<br />
[[Attribute Convention for Data Discovery (ACDD) Precedence]]<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
[[Attribute Convention for Data Discovery (ACDD) Object Conventions]]<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46637Talk:Attribute Convention for Data Discovery 1-2 Working2014-04-25T19:56:52Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|-<br />
| 11 || geospatial_vertical_min/max || The current description seems to require the values to represent the distance from earth's center || || In the vertical_positive attribute this is more clear (use same reference datum as your vertical coordinate variable uses) || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates (Nan Galbraith notes: creator might be replaced by a less ambiguous term (OceanSITES is going with principal_investigator as the data 'owner' at this point) What if there is no principal investigator, is this an institution instead of a person?.<br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
====Re: Attributes Discussed and Resolved -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 14:49, 17 February 2014 (MST)====<br />
<br />
:: Replace this text with your reply<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=46636Talk:Attribute Convention for Data Discovery 1-2 Working2014-04-25T19:36:23Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|-<br />
| 11 || geospatial_vertical_min/max || This now seems to require distance from earth's center || || If needed we should add a field to specify the reference datum; we use sea level, not center of earth || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates (Nan Galbraith notes: creator might be replaced by a less ambiguous term (OceanSITES is going with principal_investigator as the data 'owner' at this point) What if there is no principal investigator, is this an institution instead of a person?.<br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
====Re: Attributes Discussed and Resolved -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 14:49, 17 February 2014 (MST)====<br />
<br />
:: Replace this text with your reply<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45676Talk:Attribute Convention for Data Discovery 1-2 Working2014-02-17T21:59:35Z<p>NanGalbraith: /* Attributes Discussed and Resolved */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates (Nan Galbraith notes: creator might be replaced by a less ambiguous term (OceanSITES is going with principal_investigator as the data 'owner' at this point) What if there is no principal investigator, is this an institution instead of a person?.<br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
====Re: Attributes Discussed and Resolved -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 14:49, 17 February 2014 (MST)====<br />
<br />
:: Replace this text with your reply<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45675Talk:Attribute Convention for Data Discovery 1-2 Working2014-02-17T21:49:52Z<p>NanGalbraith: /* Attributes Discussed and Resolved */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates (Nan Galbraith notes: creator might be replaced by a less ambiguous erm; OceanSITES is going with principal_investigator as the data 'owner' at this point.<br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
====Re: Attributes Discussed and Resolved -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 14:49, 17 February 2014 (MST)====<br />
<br />
:: Replace this text with your reply<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45560Attribute Convention for Data Discovery 1-2 Working2014-02-07T20:41:39Z<p>NanGalbraith: /* Version and Status */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45559Attribute Convention for Data Discovery 1-2 Working2014-02-07T20:40:00Z<p>NanGalbraith: /* Version and Status */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]<br />
<br />
''(Yes, you are at the right place. The title has been modified, deleting '(ACDD)', and a version number incorporated.)''<br />
<br />
__TOC__<br />
<br />
== Version and Status ==<br />
<br />
This is the working document for updates to the ACDD convention, leading to version 1.2 of that convention. This page is under development with updated definitions, some new introductory text, and relegation of auxiliary content to separate documents.<br />
<br />
Note this document is not a full replacement of the original 1.1; that full replacement will be built upon approval of this content.<br />
<br />
The version of this ''working'' document is designated as version 1.2.3.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked in that history with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is consensus about these definitions, they will be migrated to a new version of the [[Attribute Convention for Data Discovery|primary document]].<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the top text on the [[Attribute Convention for Data Discovery 1-1]] page, until just before the Highly Recommended section.<br />
<br />
§<br />
== Version and Status ==<br />
<br />
This is version 1.2 of the ACDD convention.<br />
<br />
The target page [[Attribute Convention for Data Discovery]] will always point to the current version of this convention. As the convention is updated, the version number at the top of the page and in the URL will be updated, and the target page will redirect to the most recent version.<br />
<br />
See the [[Category:Attribute_Conventions_Dataset_Discovery category page]] for an overview of this convention and history about its development. <br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained can be found at [[Attribute_Convention_for_Data_Discovery_Working]], which redirects to the current working document, if any.<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. If additional metadata exists, you can make users aware of it by adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45481Attribute Convention for Data Discovery 1-2 Working2014-02-04T20:56:56Z<p>NanGalbraith: /* Overview */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.2.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is some consensus about a group of definitions, they will be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the text on the 'current version' page, from section Development to just before Highly Recommended.<br />
<br />
§<br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained at [[Attribute_Convention_for_Data_Discovery_(ACDD)_Working]].<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, providing definitions for NetCDF global attributes that will help data to be located efficiently. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. In order to make users aware of that additional metadata we recommend adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata. This element is not included in the current version of the NetCDF Attribute Convention for Dataset Discovery.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45480Talk:Attribute Convention for Data Discovery 1-2 Working2014-02-04T20:49:43Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix || Status<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern || Defer?<br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. Text was added with this contextual information. || DONE<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || DEFER<br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || DONE<br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || Just for discovery. || WITHDRAWN<br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || To a reasonable degree. || DEFER<br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 for Conventions?|| || Use 'ACDD-1.3', make that the updated version of final approved ACDD || DONE<br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || Yes, because they are the data types (their term in the interface) implemented for the Common Data Model. Terms are in the definition || DONE<br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || no; CF's institution is entirely ambiguous about the role || DONE<br />
|-<br />
| 10 || metadata_link || NetCDF files should be self-documenting; this gives data writers an out. Also, it's not machine-usable, since the contents of the linked page could be ... anything|| || I'd like to deprecate this (NRG) || ? <br />
|}<br />
----<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
<br />
These attributes should receive extra reviewing attention, as they have most recently changed.<br />
<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify _targeted_ spacing (and preferred format)<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; while discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
* keywords: chose to leave keywords the wild west, but with some additional options offered; a URI or prefix syntax is also OK, e.g., 'GCMD:space science'<br />
* keywords_vocabulary: in the 'wild west' spirit above, multiple keyword vocabularies can be separated by a comma, and specified in keywords attribute with a prefix (why not?); but we dropped this from Recommended to Suggested<br />
* history: reference to external history metadata can be included; we avoided conflicting with existing one-line-per-process recommendation<br />
* date_modified: name changed to date_content_modified, also added date_values_modified<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify _targeted_ spacing<br />
* creator_project, creator_institution, publisher_project, publisher_institution: ok to keep, if Suggested category is downplayed<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139) ditto<br />
* date_created: changed name to date_product_generated<br />
* date_product_generated: further updated description to reflect this is when the created file/product/package was generated (not when a stream first came into existence)<br />
* coverage_content_type: deleted this, it was a recent addition and not strongly needed<br />
* Metadata_Link: defined and made lower case<br />
<br />
'''Deprecated''':<br />
* Created this section<br />
* Metadata_Conventions: moved to deprecated, changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 20:32, 31 January 2014 (MST)<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45479Attribute Convention for Data Discovery 1-2 Working2014-02-04T20:38:55Z<p>NanGalbraith: /* Alignment with NetCDF and CF Conventions */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.2.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is some consensus about a group of definitions, they will be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the text on the 'current version' page, from section Development to just before Highly Recommended.<br />
<br />
§<br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained at [[Attribute_Convention_for_Data_Discovery_(ACDD)_Working]].<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, focusing on attributes<br />
that may be useful to help find data of interest. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF)] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. In order to make users aware of that additional metadata we recommend adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata. This element is not included in the current version of the NetCDF Attribute Convention for Dataset Discovery.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45478Attribute Convention for Data Discovery 1-2 Working2014-02-04T20:37:40Z<p>NanGalbraith: /* Suggested Changes to introductory words */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.2.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is some consensus about a group of definitions, they will be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the text on the 'current version' page, from section Development to just before Highly Recommended.<br />
<br />
§<br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained at [[Attribute_Convention_for_Data_Discovery_(ACDD)_Working]].<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, focusing on attributes<br />
that may be useful to help find data of interest. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF) ] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. In order to make users aware of that additional metadata we recommend adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata. This element is not included in the current version of the NetCDF Attribute Convention for Dataset Discovery.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45477Attribute Convention for Data Discovery 1-2 Working2014-02-04T20:36:57Z<p>NanGalbraith: /* Overview */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.2.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is some consensus about a group of definitions, they will be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the text from section Development to just before Highly Recommended.<br />
<br />
§<br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained at [[Attribute_Convention_for_Data_Discovery_(ACDD)_Working]].<br />
<br />
= Overview =<br />
The NetCDF Group at Unidata has recommended [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html attributes for data discovery] . The Attribute Convention for Data Discovery (ACDD) addresses that need, focusing on attributes<br />
that may be useful to help find data of interest. <br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
The NetCDF User Guide [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (NUG)] provides basic recommendations for creating NetCDF files; the NetCDF Climate and Forecast Metadata Conventions [http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-conventions-document-1/ (CF) ] provide more specific guidance. The ACDD builds upon and is compatible with these conventions; it may refine the definition of some terms in those conventions, but does not preclude the use of any attributes defined by the NUG or CF. <br />
<br />
The NUG does not require any global attributes, though it recommends and defines two, title and history; CF specifies many more. ACDD adopts all CF global attributes, with the exception of institution; we specify creator_institution and publisher_institution to allow more information about the data to be included.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. In order to make users aware of that additional metadata we recommend adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata. This element is not included in the current version of the NetCDF Attribute Convention for Dataset Discovery.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45476Attribute Convention for Data Discovery 1-2 Working2014-02-04T17:58:41Z<p>NanGalbraith: /* Status */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.2.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits have been made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary.<br />
<br />
Once there is some consensus about a group of definitions, they will be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2014.02.03. All major issues have been resolved in the document, pending review by the ACDD team.<br />
<br />
Details may be reviewed below the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
= Suggested Changes to introductory words =<br />
<br />
The following (between § marks) is proposed to replace the text from section Development to just before Highly Recommended.<br />
<br />
§<br />
<br />
=== Development ===<br />
<br />
Any development version of the ACDD definitions is maintained at [[Attribute_Convention_for_Data_Discovery_(ACDD)_Working]].<br />
<br />
= Overview =<br />
The netCDF metadata model is focused on providing "use metadata" for the data included in the file (or granule). The netCDF Group at Unidata has [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html recommended] netCDF attributes for data discovery. This Attribute Convention addresses that need, focusing on attributes that may be most useful to help find data of interest.<br />
<br />
== Alignment with NetCDF and CF Conventions ==<br />
ACDD is compatible with the netCDF and CF conventions, though it adds emphasis to some attributes in those conventions, and may refine those conventions' descriptions. ACDD does not preclude the use of any attributes defined by netCDF or CF.<br />
<br />
The ACDD assumes the NetCDF User Guide (NUG) is being followed; many of ACDD's users also use CF, with which ACDD is compatible. The NUG does not _require_ any global attribute, though it [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions recommends and defines several]. ACDD adds recommendations about the title and history attributes specified by the NetCDF User Guide.<br />
<br />
The Climate and Forecast convention specifies many more attributes. ACDD emphasizes comment and source, which are defined by CF both globally and as variable attributes. (If an attribute is defined globally and in a variable, the variable's attribute value has precedence in that context.) ACDD specifies creator_institution and publisher_institution and related attributes, but does not re-use CF's institution attribute because it is ambiguous.<br />
<br />
== Attribute Crosswalks == <br />
Many of these attributes correspond to general discovery metadata content, so they are available in many metadata standards. This page includes the [http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html Unidata crosswalk to THREDDS] and adds the crosswalk to ISO 19115-2. Note that the attribute names link to the Unidata definitions. Many of these elements are included in the [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_Core_Elements ISO 19115 Core] specification. They are indicated in this Table by an M, O, or C in parentheses. An “M” indicates that the element is mandatory. An “O” indicates that the element is optional. A “C” indicates that the element is mandatory under certain conditions.<br />
<br />
== Additional Metadata: metadata_link attribute ==<br />
<br />
Other metadata dialects (i.e. ISO 19115) can provide information about collections and more details about the dataset. In order to make users aware of that additional metadata we recommend adding a global attribute named "metadata_link" to the netCDF file. The value of this attribute is a URL that gives the location of the more complete metadata. This element is not included in the current version of the NetCDF Attribute Convention for Dataset Discovery.<br />
<br />
== Conformance Test ==<br />
<br />
A [https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery_Conformance_Test Conformance Test] is available for this convention.<br />
<br />
= Global Attributes = <br />
''(reformat Highly Recommended, Recommended, etc. as 2nd-level headings)''<br />
<br />
§<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also keywords_vocabulary attribute).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute is [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions defined in NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; comment : Miscellaneous information about the data, not captured elsewhere. This attribute is [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents defined in CF].<br />
; date_content_modified : The date on which any of the provided content, including data, metadata, and presented format, was last changed (ISO 8601 format)<br />
; date_values_modified: The date on which the provided data values were last changed; excludes metadata and formatting changes (ISO 8601 format)<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for originating this data.<br />
; publisher : The person responsible for the data file or product, with its current metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file or product.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
The following terms and definitions are offered in case they address your situation.<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_product_generated : The date on which this data file or product was produced/distributed (ISO 8601 format). While this date is like a file timestamp, the date_content_modified and date_values_modified should be used to assess the age of the contents of the file or product.<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; creator_uri : The unique identifier of the person principally responsible for originating this data. <br />
; creator_institution : The institution that originated this data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that originated this data.<br />
; creator_project : The scientific project that originated this data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that originated this data.<br />
; publisher_uri : The unique identifier of the person responsible for providing the data file or product. <br />
; publisher_institution : The institution that provided the data file or equivalent product; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; publisher_project : The scientific project that provided the data file or equivalent product; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that provided the data file or equivalent product; can include any information as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
<br />
== Deprecated ==<br />
<br />
The following terms and definitions are still in the specification, but are no longer recommended for use.<br />
<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
----<br />
<br />
= Additional Materials =<br />
== Mappings ACDD to other metadata dialects ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
== Recommended Order of Precedence ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
== Future Directions: Object Conventions for Data Discovery ==<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
== ISO Translation Notes ==<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45440Talk:Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:53:57Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. (was:John is working on a blended list of all attributes) ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document (standard) just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document (standard) need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 || Use ACDD-1.2.2 || <br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || <br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || delete? || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45439Talk:Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:52:56Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. (was:John is working on a blended list of all attributes) ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2 || Use ACDD-1.2.2 || <br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || <br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || delete? || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45436Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:17:15Z<p>NanGalbraith: /* Suggested */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is defined in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in ([http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents CF]).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
Note: The NUG defines title and history to be global attributes. CF adds institution, source, references, and comment, to be either global or assigned to individual variables. When an attribute appears both globally and as a variable attribute, the variable's version has precedence. ACDD does not require or define institution or references.<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45435Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:09:09Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This attribute is defined in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG].<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in ([http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents CF]).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data; can serve as an audit trail. Per the [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append an ISO Lineage reference; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45433Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:03:23Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
; source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it; this is a CF ([http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents]) attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute also appears in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45432Attribute Convention for Data Discovery 1-2 Working2014-01-31T19:02:42Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
; Source : The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it; this is a CF ([http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents]) attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute also appears in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45364Talk:Attribute Convention for Data Discovery 1-2 Working2014-01-21T19:04:39Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Nan has added NUG or CF to the attributes that are part of those standards. (was:John is working on a blended list of all attributes) ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute; ACDD originally used Metadata_Conventions attribute. Do we suggest ACDD_1.2.1? || || <br />
|-<br />
| 8 || Data type || Is the term cdm_data_type appropriate? We mean the THREDDS scientific layer; what terms are allowed? || || <br />
|-<br />
| 9 || creator_institution duplicate || does creator_institution duplicate CF's 'institution'? || || delete? || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45363Talk:Attribute Convention for Data Discovery 1-2 Working2014-01-21T18:36:23Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || John is working on a blended list of all attributes ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute. Do we suggest ACDD 1.3? || || <br />
|-<br />
| 8 || Data type || CDM data type implies a CF Discrete Sampling Geometries file, not appropriate for all files || || <br />
|-<br />
| 9 || creator_institution duplicate || creator_institution seems to duplicate CF's institution || || delete? || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45065Attribute Convention for Data Discovery 1-2 Working2013-11-22T15:37:29Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath. Please note that this is different from the CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute also appears in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45064Attribute Convention for Data Discovery 1-2 Working2013-11-22T15:36:12Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of point, profile, section, station, station_profile, trajectory, grid, image, or swath (Note that this is different from the special CF NetCDF attribute 'featureType' that indicates a Discrete Sampling Geometry file - for guidance on those terms, please see [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance].<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute also appears in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45036Attribute Convention for Data Discovery 1-2 Working2013-11-20T15:01:48Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (as described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance]), use Station; for Trajectory Time Series, use Trajectory. (Note this is different than the special CF NetCDF attribute 'featureType'.)<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This attribute also appears in [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45035Attribute Convention for Data Discovery 1-2 Working2013-11-20T14:57:25Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide ([http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG]) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (as described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance]), use Station; for Trajectory Time Series, use Trajectory. (Note this is different than the special CF NetCDF attribute 'featureType'.)<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in freetext.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45034Attribute Convention for Data Discovery 1-2 Working2013-11-20T14:55:48Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide (NUG) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a NUG attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (as described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance]), use Station; for Trajectory Time Series, use Trajectory. (Note this is different than the special CF NetCDF attribute 'featureType'.)<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance]. This is a [http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Attribute-Conventions NUG] attribute. <br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in freetext.<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45033Attribute Convention for Data Discovery 1-2 Working2013-11-20T14:52:19Z<p>NanGalbraith: /* Highly Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset; this is a NetCDF Users Guide (NUG) attribute. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
; Conventions : A list of the conventions followed by the dataset; blank space separated is recommended but commas should be used if any convention name contains blanks. This is a NUG attribute.<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (as described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance]), use Station; for Trajectory Time Series, use Trajectory. (Note this is different than the special CF NetCDF attribute 'featureType'.)<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance].<br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in freetext. <br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45032Attribute Convention for Data Discovery 1-2 Working2013-11-20T14:45:20Z<p>NanGalbraith: /* Suggested */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2.1 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
== Status ==<br />
<br />
This summarizes the status of the terms as of 2013.10.18. <br />
<br />
It also references the [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#List_of_Open_Issues open issues] in the Discussion page.<br />
<br />
These are the major remaining issues in the document.<br />
<br />
=== Attributes Without Comment ===<br />
'''Highly Recommended''': title, summary<br />
<br />
'''Recommended''': id, naming_authority, comment, processing_level, acknowledgment, geospatial_* (bounds, lat_min, lat_max, lon_min, lon_max, vertical_min, vertical_max, vertical_positive), time_coverage_start, time_coverage_end, time_coverage_duration, license (wording reordered)<br />
Suggested: geospatial_lat_units, geospatial_lon_units, geospatial_vertical_units, coverage_content_type<br />
<br />
=== Attributes Discussed and Resolved ===<br />
'''Recommended''':<br />
* cdm_data_type: all issues resolved, needs one last read.<br />
* creator, creator_email, publisher, publisher_email: no issue with updates <br />
* time_coverage_resolution: updated to specify targeted spacing (and preferred format); needs review<br />
* standard_name_vocabulary: someone pointed out this is unnecessary; in CF the standard_name vocabulary is always CF. It's deleted.<br />
* contributor_info: principal objections (ISO 19139) are resolved; discussion may be needed, but I think satisfactory structural encodings may be found and should be acceptable.<br />
<br />
'''Suggested''':<br />
* geospatial_*_resolution (lat, lon, vertical): updated to specify targeted spacing; needs review<br />
<br />
=== Attributes Under Discussion ===<br />
'''Highly Recommended''':<br />
* keywords: use type code or pseudo-groups syntax? ok to use URI in addition to selections from a vocabulary? ok to use prefix?<br />
<br />
'''Recommended''':<br />
* keywords_vocabulary: can multiple keyword vocabularies be separated by a comma and specified in keywords attribute with a prefix? (if not both, then do neither -- just use URI option in keywords)<br />
* history: had to drop ISO 19139 expression of lineage, replaced with external reference option<br />
* date_modified: recently discussed by Nan; description is updated per John's latest email in that thread<br />
* creator_url, publisher url: moved to Suggested, changed to _uri, and specified to apply to person only <br />
<br />
'''Suggested''':<br />
* creator_project, creator_institution, publisher_project, publisher_institution: do they help discovery enough to include?<br />
* creator_project_info, creator_institution_info, publisher_project_info, publisher_institution_info: (deleted ISO 19139: do _they_ help discovery enough?<br />
* date_created: recently discussed by Nan; description is updated from John's latest email in that thread<br />
<br />
'''Other''': <br />
* Metadata_Conventions: changed text significantly per separate email thread; reference John's email titled Metadata_Conventions and Metadata_Link<br />
* Metadata_Link: defined<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as derived from the Common Data Model's Scientific Data layer and understood by THREDDS (this is a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (as described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance]), use Station; for Trajectory Time Series, use Trajectory. (Note this is different than the special CF NetCDF attribute 'featureType'.)<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided by citing an ISO Lineage reference, e.g., http://www.ngdc.noaa.gov/docucomp/95BD4CCC-D27D-8DE4-E040-0AC8C5BB43B64; see [https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Lineage NOAA EDM ISO Lineage guidance].<br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which the provided content, including data, metadata, and presented format, was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the targeted time period between each value in the data set. ISO8601 duration format recommended.<br />
; license : Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in freetext. <br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to whitespace).<br />
; date_created : The date on which this data product came into existence (for products that grow by adding data, this value isn't changed by later additions of data).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the targeted spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the targeted spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the targeted vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_uri : The unique identifier of the person principally responsible for the data. <br />
; creator_institution : The institution that produced the data; should uniquely identify the institution. <br />
; creator_institution_info : Additional free text information for the institution that produced the data.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional free text information for the institution that produced the data.<br />
; publisher_uri : The unique identifier of the person responsible for the data file, its metadata and format. <br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; metadata_link : A URI that gives the location of more complete metadata; a URL is recommended.<br />
; Metadata_Convention : (deprecated, supported for backward compatibility with current usage) Reference to the particular metadata convention(s) used for the described data file; recommended practice is to add the metadata convention(s) to the comma-delimited conventions list in the 'Conventions' attribute, per NetCDF Best Practices.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45031Talk:Attribute Convention for Data Discovery 1-2 Working2013-11-19T16:41:32Z<p>NanGalbraith: /* Conventions or Metadata_Convention -- NanGalbraith (talk) 09:40, 19 November 2013 (MST) */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Any reason we can't make a blended list of all attributes? ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute. Do we suggest ACDD 1.3? || || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD-1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45030Talk:Attribute Convention for Data Discovery 1-2 Working2013-11-19T16:40:46Z<p>NanGalbraith: /* Conventions or Metadata_Convention -- ~~~~ */ new section</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Any reason we can't make a blended list of all attributes? ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute. Do we suggest ACDD 1.3? || || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.<br />
<br />
== Conventions or Metadata_Convention -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 09:40, 19 November 2013 (MST) ==<br />
<br />
We need to discuss whether to remove the existing Metadata_Conventions attribute and add ACDD_1.3 (or other) to the 'Conventions' attribute, as is recommended by the unidata guidance.<br />
<br />
From Writing NetCDF Files: Best Practices and other unidata guidance documents:<br />
<br />
If present, Conventions is a global attribute that is a character array for the name of the conventions followed by the dataset. <br />
<br />
The `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks)<br />
<br />
Document the convention you are using by adding the global attribute "Conventions" to each netCDF file, for example:<br />
:Conventions = "CF-1.3";<br />
<br />
This is under discussion on the ACDD team email:<br />
<br />
'I have always preferred the idea of using the "Conventions" attribute rather than "Metadata_Conventions". However, client support for multiple values in the "Conventions" attribute was not very good back when ACDD was originally written. And, while explicit mention of multiple values in the "Conventions" attribute have been in the NUG for some time, it is (I believe) only now slated for the next version of CF [1].<br />
<br />
Does anyone have a good sense of client support for this now?<br />
<br />
Then again, there's the chicken and egg issue. Clients will be slow to support this feature until someone starts producing data that uses this feature.' - Ethan<br />
<br />
<br />
'We should discuss the deprecation of Metadata_Conventions more closely at the next telcon. We for one are using it currently in many, many GHRSST granules.' - Ed Armstrong</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=45029Talk:Attribute Convention for Data Discovery 1-2 Working2013-11-19T16:24:56Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || Any reason we can't make a blended list of all attributes? ||<br />
|-<br />
| 3 || Guidance || How do we include/reference guidance? || [http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working#Adding_Guidance Discussion] || Every section that needs/includes guidance should have a Guidance link, that refers to the appropriate Guidance text on a separate page || <br />
|-<br />
| 4 || Undecided Terms || Resolve open issues with terms || [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Discussed_and_Resolved Resolved (review)], [http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working#Attributes_Under_Discussion Open (discuss)] || Pick an answer and keep moving || <br />
|-<br />
| 5 || Purpose of document || Is this document just for discovery? a LOT of terms are clearly not discovery || || <br />
|-<br />
| 6 || Internally complete || Does this document need to be internally complete per CF philosophy? || || <br />
|-<br />
| 7 || Conventions attribute || NUG recommends putting all conventions into this single attribute. Do we suggest ACDD 1.3? || || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-1&diff=44829Talk:Attribute Convention for Data Discovery 1-12013-10-09T18:49:47Z<p>NanGalbraith: /* add syntax for list of contributors -- ~~~~ */ new section</p>
<hr />
<div>== Include definitions for id, naming_authority -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 12:01, 9 May 2013 (MDT) ==<br />
<br />
We should provide definitions for id and naming_authority first and then describe the combination of the two terms second.<br />
<br />
== add syntax for list of contributors -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 12:49, 9 October 2013 (MDT) ==<br />
<br />
Are contributor names and roles to be comma-separated lists? Semicolons? Something else?</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44758Talk:Attribute Convention for Data Discovery 1-2 Working2013-09-30T14:44:05Z<p>NanGalbraith: /* Re: Feature Types (cdm and otherwise) -- NanGalbraith (talk) 13:15, 9 September 2013 (MDT) */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || <br />
|-<br />
| 3 || || || || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
====Re: Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:44, 30 September 2013 (MDT)====<br />
<br />
:: The term cdm_datatype seems to have originated with ACDD, and it's a poor choice of terms, IMHO, since most THREDDS docs use 'data type' to mean float/int etc. Also, we might want to point to the actual unidata document that defines what we are calling cdm_data_types, at http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/PointDatatype.html That page uses the term Observation Datatypes, which is not really any more explicit than cdm_data_type. Feature type is more descriptive, but (as above) it's an overloaded CF attribute.<br />
<br />
From the unidata page linked above, these are the definitions of the types:<br />
<br />
"Several types of observation collections are described in the Common Data Model's Scientific Datatype layer. A Point Observation dataset contains observations which are not necessarily related in space or time. A Station Observation dataset contains time series of observations at named locations called stations. A trajectory is a collection of observations which are connected along a one dimensional track in space, with time increasing monotonically along the track. A Trajectory Observation dataset contains one or more trajectories."<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44717Talk:Attribute Convention for Data Discovery 1-2 Working2013-09-19T17:58:38Z<p>NanGalbraith: /* List of Open Issues */</p>
<hr />
<div>== List of Open Issues ==<br />
<br />
You may add to this list (each issue gets a row). <br />
<br />
Also, soon someone will read all the comments below, and consolidate the open issues into this list.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Issue number || Issue name !! Description !! Reference below !! Recommended fix<br />
|-<br />
| 1 || Roles in Suggested section || Cleanup requested; current selection of role_entity not satisfactory || || Ted, John et al create more precise definition of <role>_<entity> substitutable pattern <br />
|-<br />
| 2 || Attributes that are part of NUG or CF || Identify which, if any, terms on our list are actually defined by another standard || || <br />
|-<br />
| 3 || || || || <br />
|}<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 14:40, 17 September 2013 (MDT) I'm in favor of using the ISO terms. Note: The definitions above are not the ones I found in ISO; the definitions in ISO are a little bit further down, and are hopelessly self-referencing.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44701Talk:Attribute Convention for Data Discovery 1-2 Working2013-09-09T19:15:05Z<p>NanGalbraith: /* Feature Types (cdm and otherwise) -- Graybeal (talk) 17:40, 20 May 2013 (MDT) */</p>
<hr />
<div>== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
===Re: Feature Types (cdm and otherwise) -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:15, 9 September 2013 (MDT)===<br />
<br />
featureType is a special NetCDF attribute in CF; it gives the type of Discrete Sampling Geometry, and its presence indicates that the file contains DSG features. This opens a whole set of expectations fr the file contents, and some limitations on the dimensions and coordinates allowed. We should stick with cdm_data_type, in my opinion - although I have to ask if it is actually a discovery attribute.<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44700Talk:Attribute Convention for Data Discovery 1-2 Working2013-09-06T19:09:04Z<p>NanGalbraith: /* People and Institutions -- Ted.Habermann (talk) 13:55, 4 June 2013 (MDT) */</p>
<hr />
<div>== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.<br />
<br />
===Re: People and Institutions -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 13:09, 6 September 2013 (MDT)===<br />
<br />
I replaced _info fields with _url and _email for creator and publisher, because I agree that these are easier to parse. I would like to move the _url fields (along with a few others) from the Recommended section to Suggested, or possibly to add a category that isn't so much suggested as ... ''might be to be considered''. The creator_institution_info, creator_project*, publisher_institution*, and publisher_project* fields don't aid in discovery enough to include them, in my opinion.</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44698Attribute Convention for Data Discovery 1-2 Working2013-09-05T19:40:51Z<p>NanGalbraith: /* Suggested */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as understood by THREDDS (a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType]THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance], use Station; for Trajectory Time Series, use Trajectory.<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided using the ISO Lineage model, expressed per ISO 19139.<br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which this dataset (as seen by users or captured in a file) was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; creator_url : The address of the person or the institution principally responsible for the data. <br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; publisher_url : The address of the person or the institution responsible for the data file, its metadata and format. <br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth, positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the time period between each value in the data set.<br />
; standard_name_vocabulary : The unique name or identifier of the controlled vocabulary from which variable standard names are taken. If more than one controlled vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that standard names may optionally be prefixed with the controlled vocabulary key.<br />
; license : Provide the URL to a standard or specific license, describe any restrictions to data access and distribution, or enter "Freely Distributed" or "None".<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals or institutions that contributed to the creation of this data. May be presented as free text, or in a format compatible with ISO 19139.<br />
; date_created : The first date on which this dataset was published (this value never changes after first set of data is released the first time).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the vertical spacing of points. <br />
; coverage_content_type : Information about the content of the file, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_institution_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
<br />
==Issues for Discussion==<br />
The following terms were omitted from the previous version. We should determine if this is intentional and if so, we should determine if there is an equivalent concept.<br />
<br />
;Metadata_Link : See http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29#Metadata_Link for definition. Also, we should determine our position on case sensitivity i.e. if we keep Metadata_Link, can we change the capitalization?<br />
<br />
;Metadata_Convention : While this term is not present in the table it is in the examples section. It is being used in practice (e.g. IOOS glider convention draft, and OceanSITES). In practice the following usage is observed: <attribute name="Metadata_Conventions" value="Unidata Dataset Discovery v1.0"/>. TODO: Determine if we will standardize the definition and usage. If we standardize usage, we should determine a recommended way of referring to ACDD and move past the Unidata reference.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44697Attribute Convention for Data Discovery 1-2 Working2013-09-05T19:38:08Z<p>NanGalbraith: /* Suggested */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as understood by THREDDS (a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType]THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance], use Station; for Trajectory Time Series, use Trajectory.<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided using the ISO Lineage model, expressed per ISO 19139.<br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which this dataset (as seen by users or captured in a file) was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; creator_url : The address of the person or the institution principally responsible for the data. <br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; publisher_url : The address of the person or the institution responsible for the data file, its metadata and format. <br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth, positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the time period between each value in the data set.<br />
; standard_name_vocabulary : The unique name or identifier of the controlled vocabulary from which variable standard names are taken. If more than one controlled vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that standard names may optionally be prefixed with the controlled vocabulary key.<br />
; license : Provide the URL to a standard or specific license, describe any restrictions to data access and distribution, or enter "Freely Distributed" or "None".<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals or institutions that contributed to the creation of this data. May be presented as free text, or in a format compatible with ISO 19139.<br />
; date_created : The first date on which this dataset was published (this value never changes after first set of data is released the first time).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the spacing of points in latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the spacing of points in longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Information about the vertical spacing of points. <br />
; converage_content_type : Information about the content of the variable, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_institution_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
<br />
==Issues for Discussion==<br />
The following terms were omitted from the previous version. We should determine if this is intentional and if so, we should determine if there is an equivalent concept.<br />
<br />
;Metadata_Link : See http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29#Metadata_Link for definition. Also, we should determine our position on case sensitivity i.e. if we keep Metadata_Link, can we change the capitalization?<br />
<br />
;Metadata_Convention : While this term is not present in the table it is in the examples section. It is being used in practice (e.g. IOOS glider convention draft, and OceanSITES). In practice the following usage is observed: <attribute name="Metadata_Conventions" value="Unidata Dataset Discovery v1.0"/>. TODO: Determine if we will standardize the definition and usage. If we standardize usage, we should determine a recommended way of referring to ACDD and move past the Unidata reference.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44696Attribute Convention for Data Discovery 1-2 Working2013-09-05T19:30:48Z<p>NanGalbraith: /* Recommended */</p>
<hr />
<div>[[Category: Attribute Conventions Dataset Discovery]]<br />
== Version and Status ==<br />
<br />
This version is designated as Version 1.2 beta.<br />
<br />
This page is under development with updated definitions.<br />
<br />
= Introduction =<br />
<br />
This page consolidates ongoing work seeking to improve the definitions in the [[Attribute Convention for Data Discovery (ACDD)]].<br />
<br />
The first 3 sections represent the terms in the corresponding sections of the ACDD.<br />
<br />
Modifications relative to the original text may be seen with the history mechanism of this wiki. The original definitions are marked with the Summary keyword Original Definitions.<br />
<br />
== Process ==<br />
<br />
The edits will be made in this page by anyone in the community who wishes to contribute, and discussed in greater depth in the Discussion page, if necessary. (The discussion page can also be used as an archive of changes on this page, if desired.)<br />
<br />
Once there is some consensus about one or a group of definitions, they can be migrated to the [[Attribute Convention for Data Discovery (ACDD)|primary document]] and the version number of that document incremented.<br />
<br />
= Working Definitions =<br />
<br />
== Highly Recommended ==<br />
<br />
; title : A short phrase or sentence describing the dataset. <br />
; summary : A paragraph describing the dataset, analogous to an abstract for a paper.<br />
; keywords : A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary, or URIs for terms from a controlled vocabulary (see keyword_vocabulary below).<br />
<br />
== Recommended ==<br />
<br />
; id : An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks.<br />
; naming_authority : The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute.<br />
; keywords_vocabulary : If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key.<br />
; cdm_data_type : The organization of the data, as understood by THREDDS (a [http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType]THREDDS "dataType"]). One of Grid, Image, Station, Swath, and Trajectory. For points, profiles, and time series (described in [http://www.nodc.noaa.gov/data/formats/netcdf/ this NODC guidance], use Station; for Trajectory Time Series, use Trajectory.<br />
; history : Describes the processes/transformations used to create this data. A simple description includes one line per process, listing the sources for each process; a more complete description can be provided using the ISO Lineage model, expressed per ISO 19139.<br />
; comment : Miscellaneous information about the data, not captured elsewhere.<br />
; date_modified : The date on which this dataset (as seen by users or captured in a file) was last changed.<br />
; creator : The name of the person principally responsible for originating this data. <br />
; creator_email : The email address of the person principally responsible for the data in the file.<br />
; creator_url : The address of the person or the institution principally responsible for the data. <br />
; publisher : The person responsible for the data file, its metadata and format. <br />
; publisher_email : The email address of the person responsible for the data file, its metadata and format.<br />
; publisher_url : The address of the person or the institution responsible for the data file, its metadata and format. <br />
; processing_level : A textual description of the processing (or quality control) level of the data.<br />
; acknowledgement : A place to acknowledge various type of support for the project that produced this data.<br />
; geospatial_bounds : Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.<br />
; geospatial_lat_min : Describes a simple lower latitude limit; may be part of a bounding box or cube. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.<br />
; geospatial_lat_max : Describes a simple upper latitude limit; may be part of a bounding box or cube. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.<br />
; geospatial_lon_min : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_min specifies the westernmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_lon_max : Describes a simple longitude limit; may be part of a bounding box or cube. Geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min.<br />
; geospatial_vertical_min : Describes a numerically smaller vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset.<br />
; geospatial_vertical_max : Describes a numerically larger vertical limit; may be part of a bounding box or cube. If geospatial_vertical_positive is up ('altitude' orientation), the geospatial_vertical_min attribute specifies the location furthest from the earth's center covered by the dataset. If geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the location closest to the earth's center covered by the dataset.<br />
; geospatial_vertical_positive : One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth, positive values correspond to below the reference datum.<br />
; time_coverage_start : Describes the time of the first data point in the data set. ISO8601 format recommended.<br />
; time_coverage_end : Describes the time of the last data point in the data set. ISO8601 format recommended.<br />
; time_coverage_duration : Describes the duration of the data set. ISO8601 duration format recommended.<br />
; time_coverage_resolution : Describes the time period between each value in the data set.<br />
; standard_name_vocabulary : The unique name or identifier of the controlled vocabulary from which variable standard names are taken. If more than one controlled vocabulary is used, each may be presented with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard Names") and a following comma, so that standard names may optionally be prefixed with the controlled vocabulary key.<br />
; license : Provide the URL to a standard or specific license, describe any restrictions to data access and distribution, or enter "Freely Distributed" or "None".<br />
<br />
== Suggested ==<br />
<br />
; contributor_info : The name and role of any individuals or institutions that contributed to the creation of this data. May be presented as free text, or in a format compatible with ISO 19139.<br />
; date_created : The first date on which this dataset was published (this value never changes after first set of data is released the first time).<br />
; geospatial_lat_units : Units for the latitude axis. These are presumed to be "degree_north"; other options from udunits may be specified instead.<br />
; geospatial_lat_resolution : Information about the resolution of the latitude. (Format is not prescribed.)<br />
; geospatial_lon_units : Units for the longitude axis. These are presumed to be "degree_east"; other options from udunits may be specified instead.<br />
; geospatial_lon_resolution : Information about the resolution of the longitude. (Format is not prescribed.)<br />
; geospatial_vertical_units : Units for the vertical axis. These are presumed to be "meter" (of depth); other options from udunits may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar.<br />
; geospatial_vertical_resolution : Further refinement of the geospatial bounding box can be provided by using these units and resolution attributes.<br />
; converage_content_type : Information about the content of the variable, valid values are image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, coordinate.<br />
; creator_institution_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; creator_project : The scientific project that produced the data; should uniquely identify the project. <br />
; creator_project_info : Additional information for the institution that produced the data; can include any information as ISO 19139 or free text.<br />
; publisher_institution : The institution that published the data file; should uniquely identify the institution. <br />
; publisher_institution_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
; publisher_project : The scientific project that published the data; should uniquely identify the project. <br />
; publisher_project_info : Additional information for the institution that published the data; can include any information as ISO 19139 or free text.<br />
<br />
==Issues for Discussion==<br />
The following terms were omitted from the previous version. We should determine if this is intentional and if so, we should determine if there is an equivalent concept.<br />
<br />
;Metadata_Link : See http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29#Metadata_Link for definition. Also, we should determine our position on case sensitivity i.e. if we keep Metadata_Link, can we change the capitalization?<br />
<br />
;Metadata_Convention : While this term is not present in the table it is in the examples section. It is being used in practice (e.g. IOOS glider convention draft, and OceanSITES). In practice the following usage is observed: <attribute name="Metadata_Conventions" value="Unidata Dataset Discovery v1.0"/>. TODO: Determine if we will standardize the definition and usage. If we standardize usage, we should determine a recommended way of referring to ACDD and move past the Unidata reference.<br />
<br />
<br />
----<br />
<br />
= Mappings ACDD to other metadata dialects =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Mappings<br />
<br />
= Recommended Order of Precedence =<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Precedence<br />
<br />
=Future Directions: Object Conventions for Data Discovery=<br />
http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_Object_Conventions<br />
<br />
=ISO Translation Notes=<br />
http://wiki.esipfed.org/index.php?title=Attribute_Convention_for_Data_Discovery_(ACDD)_ISO_TranslationNotes<br />
[[Category:Attribute Conventions Dataset Discovery]]<br />
[[Category: Documentation Cluster]]</div>NanGalbraithhttps://wiki.esipfed.org/w/index.php?title=Talk:Attribute_Convention_for_Data_Discovery_1-2_Working&diff=44551Talk:Attribute Convention for Data Discovery 1-2 Working2013-07-30T15:04:17Z<p>NanGalbraith: /* Re: Summary of Changes re Publisher/Creator -- NanGalbraith (talk) 08:40, 30 July 2013 (MDT) */</p>
<hr />
<div>== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013:<br />
<br />
It might be a good idea to cross check against the definitions that NODC has added - as part of their NetCDF template project they wrote some better descriptions. They're at http://www.nodc.noaa.gov/data/formats/netcdf/ <br />
<br />
There are a few categories of terms that need better definitions, IMHO. <br />
<br />
1. people: <br />
creator_name (recommended)<br />
publisher_name (suggested)<br />
<br />
In a 'normal' research/observing/modeling situation, who are these people? <br />
<br />
I think there are 2 necessary points of contact, the person who 'owns' the research and gives you the go-ahead to use/publish the data, and the person who put the data into the file and/or on line. You don't really need to know how to contact the other contributors, even if they had equally or more important roles.<br />
<br />
I believe that NODC recommends naming the principal investigator as the 'creator' - although in some circumstances there is no single PI, so maybe we should say this is the person who grants the use of the data.<br />
<br />
I'm using the publisher as the person who wrote the actual file that contains the terms, and I'm listing co-PIs and data processors as contributors.<br />
<br />
''Other comments are moved below. jbg''<br />
<br />
===''Summary of Changes re Publisher/Creator''===<br />
<br />
I went with Publisher Name, Creator Name, Publisher Info (rich metadata), Creator Info (rich metadata), and Contributor Info (rich metadata); the latter could include owner or any other person/role. All of the 'rich metadata' items could include s role explicitly, presumably from a controlled vocabulary; either the same role or (if you want to create havoc) a different one.<br />
<br />
I deleted creator_email and creator_url; if you want to add those, do it in the Info field.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:23, 20 May 2013 (MDT)<br />
<br />
<br />
====Re: ''Summary of Changes re Publisher/Creator'' -- [[User:NanGalbraith|NanGalbraith]] ([[User talk:NanGalbraith|talk]]) 08:40, 30 July 2013 (MDT)====<br />
<br />
:: I noticed that there was no publisher, just publisher institution etc, so I added publisher with a definition of ''The person responsible for the data file, its metadata and format.'' <br />
<br />
Is that the definition we're using? <br />
<br />
I think we have reached consensus that the _info fields are too difficult to parse (Ted's comment); should we go back to _email and _url? <br />
<br />
Also, I moved a lot of these out of the 'recommended' category: creator_institution_info, publisher_institution, publisher_institution_info, publisher_project*<br />
<br />
<br />
One last pitch: with thanks for reminding me, to Mike McCann:<br />
<br />
These terms exist in ISO CI_RoleCodes, so why are we not using them?<br />
<br />
publisher - The person responsible for the data file, its metadata and format.<br />
<br />
principalInvestigator - The person who is responsible for the science content and intellectual property of the dataset<br />
<br />
originator - (alternate for principalInvestigator) the person or institution responsible for the science and intellectual property in the dataset, when there is no principalInvestigator<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Ted 4/22/2013: Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:48, 3 May 2013 (MDT)===<br />
<br />
: Nan 4/26/2013: One other item that I think we might need to have - beyond better definitions for some of the existing terms - is a CV for contributor roles. I think one exists, somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really be free text?<br />
<br />
====Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:49, 3 May 2013 (MDT)====<br />
<br />
:: John 4/26/2013: Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set. <br />
<br />
:: I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).<br />
<br />
=====Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:50, 3 May 2013 (MDT)=====<br />
<br />
::: Ted 4/26/2013: I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...<br />
<br />
::: What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.<br />
<br />
======Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:53, 3 May 2013 (MDT)======<br />
<br />
:::: Derrick S: Codelists can be seen as antithetical to the CF goal of creating self describing files. Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF? The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:00, 3 May 2013 (MDT)=======<br />
<br />
::::: Edward A: Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.<br />
<br />
=======Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:58, 3 May 2013 (MDT)=======<br />
<br />
::::: Nan 4/26/2013: I think we can use terms from a CV, but they should be meaningful, not URLs or those lovely 5 character codes that hark back to languages we've forgotten we ever knew.<br />
<br />
::::: We can select one CV, or we can add a term 'rolecode_vocabulary' (that would be fairly reasonable, since we're already using 'keyword_vocabulary').<br />
<br />
::::: The SDN roles below are new, but the ISO roles are from a slightly outdated page at NODC. I just find this format easier to look at than the full xml and csv formats that are available on line.<br />
<br />
::::: Personally, neither of these is very appealing - I hope the new ISO codes will be better.<br />
<br />
'''SeaDataNet roles'''<br />
* metadata collator: Responsible for the compilation of metadata for one or more datasets and submission of that metadata to the appropriate SeaDataNet metadata repository.<br />
* programme operation responsibility: Responsible for the operation of a data collecting programme.<br />
* programme archive responsibility: Responsible for the archive centre handling distribution of delayed mode data from a collecting programme and the long term stewardship of its data.<br />
* programme realtime responsibility: Responsible for the centre handling distribution of true and near real time data from a collecting programme.<br />
* contact point: Person responsible for the provision of information in response to queries concerning the metadata or underlying data.<br />
* principal funder: Person or organisation that funds the majority of an activity. contributing funder: Person or organisation that contributes to the funding of an activity.<br />
* principal investigator: Scientific lead of data collection within a programme<br />
<br />
<br />
'''ISO roles'''<br />
* resourceProvider: party that supplies the resource<br />
* custodian: party that accepts accountability and responsability for the data and ensures appropriate care and maintenance of the resource<br />
* owner: party that owns the resource<br />
* sponsor: party that sponsors the resource<br />
* user: party who uses the resource<br />
* distributor: party who distributes the resource<br />
* originator: party who created the resource<br />
* pointOfContact: party who can be contacted for acquiring knowledge about or acquisition of the resource<br />
* principalInvestigator: key party responsible for gathering information and conducting research<br />
* processor: party who has processed the data in a manner such that the resource has been modified<br />
* publisher: party who published the resource<br />
* author: party who authored the resource<br />
* collaborator: party who conducted or contributed to the research<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:03, 3 May 2013 (MDT)========<br />
<br />
:::::: Thanks for aggregating these terms. I agree none of these role vocabularies are very appealing, but I suspect that's because the world they describe is messy. I do not see how a single vocabulary can satisfy everyone's needs, especially for keywords; nor how naming the vocabulary title creates an unambiguous reference that everyone can use to look up terms from it. I guess I'm just stuck on the lack of provided functionality in this respect.<br />
<br />
========Re: Re: Re: Re: Re: Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:10, 3 May 2013 (MDT)========<br />
<br />
:::::: Ted H 4/27/2013: The suggestion to add an attribute called rolecode_vocabulary demonstrates very well the problem with this approach - a community has a documentation need and, in order to address that need, we need to add a new concept into the convention. Do we end up with a *_vocabulary attribute for every attribute that can benefit from a shared vocabulary? I think this would be difficult to maintain.<br />
<br />
:::::: As an alternative, we create a responsibleParty type group that includes a role from a shared vocabulary and information that describes people or organizations. The role has a value and a source which is the shared vocabulary that it comes from. <br />
<br />
:::::: Are we a community of convention users or convention developers? When we say we need a mechanism for describing responsibleParties that includes a role from a shared vocabulary and descriptive information, we are convention developers. When we say we need a vocabulary to describe roles like principleInvenstigator or instrumentDeveloper, we are acting as a community using a convention. <br />
<br />
:::::: What I am trying to do is separate these two roles so that when a community says "we need a shared vocabulary for x", we do not have to add a new attribute called x_vocabulary to the convention.<br />
<br />
===Re: -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:09, 3 May 2013 (MDT)===<br />
<br />
: Ken C 4/27/2013: All we say at NODC in our netCDF templates for the creator_ attributes is copied below… we discussed attributes like this a lot when documenting our templates and finally "settled" on the idea of creator being associated with "collector" of the data. Of course even that is not perfect. We don't say anything about PIs, since as Nan points out there is often no single PI. I would add that there is often no PI at all… many, many, datasets come to us now as a result of sustained and operational observing programs and systems, where the idea of a "PI" itself doesn't even apply.<br />
<br />
: * creator_email: Email address of the person or institution that collected the data. -- The email of the person or institution may be found in the NODC tables for persons (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) and institutions(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution). Use the short name of the institution if available.<br />
: * creator_name: Name of the person who collected the data. -- Use the name from the NODC persons(http://www.nodc.noaa.gov/cgi-bin/OAS/prd/person) table when applicable.<br />
: * creator_url: The URL of the institution that collected the data. -- The url of the institution can be found in the NODC institutions (http://www.nodc.noaa.gov/cgi-bin/OAS/prd/institution) table<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 16:44, 3 May 2013 (MDT) ==<br />
<br />
Nan 4/22/2013: There are a few categories of terms that need better definitions, IMHO. ''(continued)''<br />
<br />
=== 2. file times ===<br />
<br />
* date_created (recommended)<br />
* date_modified (suggested)<br />
* date_issued (suggested)<br />
<br />
These could well have different meanings for model data; for my in situ data, I have 2 (or, for real time data, possibly 3) useful file times; the time the last edit or processing occurred, which is the version information and could be useful if the underlying data has been changed, and the time the file was written, which could provide information about translation errors being corrected. (We don't update files, we overwrite them; some people might need to describe the time the original file was written and time of last update?) For real time data it could also be interesting to know the last time new data arrived, which could be asynchronous.<br />
<br />
NODC doesn't seem to use date_issued, but they have defs for created and modified.<br />
* date_created: "The date or date and time when the file was created.... This time stamp will never change, even when modifying the file." <br />
* date_modified: This time stamp will change any time information is changed in this file.<br />
<br />
==='' Summary of Changes re File Times ''===<br />
<br />
If there is the concept of date_modified, it has to be the last time the data changed (as the public sees it). That's the most important metadata of all, so now it's in the Recommended section.<br />
<br />
If that is date_modified, then date_created has to be the original creation date, when information was first available on this file. <br />
<br />
I could not think of a non-bizarre use case for date_issued, so I deleted it.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:25, 20 May 2013 (MDT)<br />
<br />
=== 3. Keywords ===<br />
<br />
Since iso uses keyword type codes instead of cramming all the possible keywords (theme, place, etc) into one structure, I don't see why we don't do something similar. We could use our pseudo-groups syntax; keywords_theme, keywords_dataCenter ...etc.<br />
<br />
==='' Summary of Changes re Keywords ''===<br />
<br />
I created an arcane way to specify multiple keyword vocabularies, and implicitly allowed it to specify prefixes for the keyword field (e.g., "CF:air_temperature, IOOS_Key:Nutrients, My Favorite Keyword, AirTemperature"). I opened up the format (it's free text, why not), which leaves the battle to be fought over best practices.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:30, 20 May 2013 (MDT)<br />
<br />
====Re: 3. Keywords -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:13, 3 May 2013 (MDT)====<br />
<br />
:: Not sure how the type codes are being considered in this context, as additional attributes or as an organizing technique inside the keywords attribute?<br />
<br />
:: I consider it a fail that there is no agreed way to support two keyword vocabularies. I therefore propose the following: If a keyword is a URI, it does not have to be a member of the Keyword Vocabulary (because its vocabulary can be derived through other means). <br />
<br />
:: I wish there were a way that Keywords and Keyword Vocabulary could have a default treatment that makes these two fields fully computer-friendly. Could we permit the Keyword Vocabulary format to be a URI, or to be specified as Name|URI, wiki-like.<br />
<br />
=== 4. coordinate 'resolution' terms ===<br />
<br />
The word resolution is a poor choice, and if it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and not an indication of the precision of the coordinate. For measurements that are irregularly spaced along a mooring line, it's fairly useless - unless we come up with a vocabulary describing this and other possible values. <br />
<br />
For my data, the term might be more useful with the other definition; our depths are approximate 'target depths', and, while we may know the lat/long of an anchor and of a buoy (the latter being a time series, the former being a single point) we don't actually know the lat/long of any given instrument on a mooring line. The watch circle of the buoy is really the 'resolution' we need to supply here.<br />
<br />
====Re: 4. coordinate 'resolution' terms -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:27, 3 May 2013 (MDT)====<br />
<br />
:: Ooh, good point. I think in context of geospatiotemporal ''coverage'', 'resolution' is a meaningful word, but without a definition it's wide open to misinterpretation. <br />
<br />
:: Your need is in regard to the measurements/locations provided for the data, right? The three terms that often get used to satisfy your need are precision, accuracy, and error. Can they be specified by the corresponding variable attributes?<br />
<br />
== -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 18:31, 3 May 2013 (MDT) ==<br />
<br />
==Adding Guidance==<br />
<br />
Do we want to provide any guidance, in addition to the definition?<br />
<br />
===Re: Adding Guidance -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:36, 5 May 2013 (MDT)===<br />
<br />
:Guidance is incredibly important on many levels. I think it is really important to integrate the guidance into the conformance tool. We have done this more in the ISO rubric then in the ACDD rubric. The rubric results include the links to the guidance and examples... This ends up providing an integrated evaluate / improve environment...<br />
<br />
==Computability==<br />
<br />
I often try to make the definition of a parameter clear enough that a computer could recognize and do something with the answer. Is that strongly desirable, weakly desirable, or not of interest?<br />
<br />
==='' Summary of Approach re Computability ''=== <br />
<br />
Some of us find it strongly desirable, but not enough to enforce it throughout. So I added it as an option in a number of places, and tried to encourage it with some of the definitions.<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:32, 20 May 2013 (MDT)<br />
<br />
==Cross-Referencing==<br />
<br />
There are other pages with guidance and discussion about these terms. Do we want to refer the user explicitly to them, either in the document as a whole or in specific terms?<br />
<br />
===Re: Cross-Referencing -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:37, 5 May 2013 (MDT)===<br />
<br />
: See Guidance discussion above<br />
<br />
== Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:16, 5 May 2013 (MDT) ==<br />
<br />
Organizations and people play many roles in the scientific data life-cycle. There are two ways that those roles can be reflected in a metadata record: by position and by code. Many metadata managers are familiar with the roles by position approach because it is used in the FGDC CSDGM. The person referenced from the metadata section is the metadata contact, the person referenced from the distribution section is the distributor, and so on. Using this approach means that the object that holds information about organizations/people does not need a role indicator. That information is inferred by the position in the structure.<br />
<br />
The ISO Standards combine the roles-by-position approach with the roles-by-code approach. Roles can generally be inferred from the positions of CI_ResponsibleParty objects in the structure, but flexibility is increased by adding a code for role to the each object. This is helpful when citing a dataset that involves people in multiple roles (principle investigator, publisher, author, resourceProvider) or when specifying the point of contact for a particular section.<br />
<br />
The roles-by-position approach allows the roles of the people involved with a dataset to be known when they are accessed separately. For example, the xPath /gmi:MI_Metadata/gmd:contact can be used if one were interested in the metadata contact for a resource. A more general xPath (//gmd:CI_ResponsibleParty) can be used to answer the question “what people or organizations are associated with this dataset”. In the latter case, the role code provides information about roles even though the people are being accessed independent of the structure.<br />
<br />
Multiple CI_ResponsibleParties can be included in almost all ISO objects that can include CI_ResponsibleParties. In those cases, roleCodes can be used to associate appropriate roles with particular organizations people if necessary. For example, the ISO CI_Citation object is used to refer to a variety of resources that are not included in a metadata record. It is modeled after a bibliographic reference and can include any number of organizations or people (CI_ResponsibleParties) in any roles. Typically a CI_Citation includes originators or authors and a publisher.<br />
<br />
===Re: Roles-by-Position vs. Roles-by-Code -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 09:45, 5 May 2013 (MDT)===<br />
: The discussion of role codes is interesting from many points of view. The lack of groups in the netCDF model essentially eliminates both of these approaches from consideration. There is no structure to attach organizations or people to and there are no objects to attach roles to. The only remaining alternative is the "named element" approach in which the name of the element includes the role. Are there advantages to that?<br />
<br />
== creator_name and institution definitons. -- [[User:Dpsnowden|Dpsnowden]] ([[User talk:Dpsnowden|talk]]) 13:05, 9 May 2013 (MDT) ==<br />
<br />
The definition of creator_name is now<br />
<dl><br />
<dt>creator_name</dt><br />
<dd>The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.</dd><br />
</dl><br />
<br />
The discussion about the roles for individuals is elsewhere in the document. My point here is that the second sentence of the existing definition includes a description of some action that will be taken. While many of us know that the actor in this case is ncISO, not everyone does. Further, we're conflating two concepts, the definition of a term and the use of that term in a particular use case (i.e. translation to ISO 10115* via ncISO). I propose that for this definition in particular and for the entire wiki in general, that we strive to separate these two concepts in the text. Let's first state what ACDD is, and what each term means, and then state one of the admittedly most common use cases.<br />
<br />
==='' Summary of Approach re Using Terms in Use Cases ''===<br />
<br />
Strove to separate the concept of how it is used from the concept of a term's definition. (One place you can't do that is in the cdm_feature term, which is very explicit about its connection to THREDDS features.)<br />
<br />
--[[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:34, 20 May 2013 (MDT)<br />
<br />
== Feature Types (cdm and otherwise) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 17:40, 20 May 2013 (MDT) ==<br />
<br />
The Unidata ACDD says <br />
:The "cdm_data_type" attribute gives the THREDDS data type appropriate for this dataset. E.g., "Grid", "Image", "Station", "Trajectory", "Radial". Its use is recommended.<br />
<br />
The NOAA ACDD says<br />
:The THREDDS data type appropriate for this dataset<br />
This is what ours currently says.<br />
<br />
The NODC guidance says <br />
:This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current choices are: Grid, Image, Station, Swath, and Trajectory. These data types do not map equally to the CF feature types. If the CF feature type = Trajectory Time Series, use "Trajectory"; if Point, Profile, or Time Series Profile, use "Station".<br />
<br />
The actual THREDDS list is called either dataTypes (code) or dataType Types (doc header), and has the same 5 types listed in the NODC guidance.<br />
<br />
If you look up "netcdf feature type" the first link is http://www.unidata.ucar.edu/software/netcdf-java/reference/FeatureDatasets/Overview.html, which says the choices are ANY, NONE; GRID, RADIAL, SWATH, IMAGE; and ANY_POINT, which encompasses POINT, PROFILE, SECTION, STATION, STATION_PROFILE, and TRAJECTORY.<br />
<br />
I went with something NODC-like, though it killed me not to include radial, station_profile, etc.<br />
<br />
== Depth (!) -- [[User:Graybeal|Graybeal]] ([[User talk:Graybeal|talk]]) 19:17, 20 May 2013 (MDT) ==<br />
<br />
Depth is fraught. <br />
<br />
(0) Vertical positive: I almost made this required. Instead, I moved it from Suggested to Recommended. Obvious reasons.<br />
<br />
(1) Vertical min/max: I didn't see in casual inspection a clear practice for min/max specification as a function of vertical_direction_positive = up or down. So I reused a convention established, after long thought, by OOI CI, and documented [https://confluence.oceanobservatories.org/display/CIDev/Coordinate+Systems+and+Coordinate+Transformations#CoordinateSystemsandCoordinateTransformations-Vertical here]. Trust me, there is one other option for a convention, and it is at least as confusing if not more so.<br />
<br />
(2) Vertical units: I assume we are not going to insist on depth as the only vertical coordinate, so I explicitly mention pressure and the use of bar.<br />
<br />
== People and Institutions -- [[User:Ted.Habermann|Ted.Habermann]] ([[User talk:Ted.Habermann|talk]]) 13:55, 4 June 2013 (MDT) ==<br />
<br />
The definitions that John proposed are helpful, but raise several issues. Before, we had eight attributes with roles embedded in their names (creator_name, _url, _email, publisher_name, _url, _email, contributor_name, _role) now we have twelve proposed. Many of these proposals would encourage the concatenation of multiple information elements into single fields (contributor_info, ...) with a recommendation of using vcard, ISO 19139 or free text. I am not aware of a mechanism for including ISO 19139 in netCDF attributes. Remember that NcML has the content as XML attributes which makes it fundamentally impossible to embed XML in them and very ugly to embed delimited text. This makes it likely that freetext would be the format of choice. This creates information blobs that are many times difficult to untangle and use, particularly for machines. It is also not clear how we deal with datasets that have multiple creators from multiple institutions. This is a very common circumstance these days. I am not aware of a mechanism for connecting appropriate creator_persons to appropriate creator_institutions when there are multiple occurrences of each. In fact, I do not know of an unambiguous way to include multiple creators in netCDF as it is currently implemented.</div>NanGalbraith