ASTM E1948-98

NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E 1948 – 98
Standard Guide for
Analytical Data Interchange Protocol for Chromatographic
Data
This standard is issued under the fixed designation E 1948; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (e) indicates an editorial change since the last revision or reapproval.
1. Scope E 1947 Specification for Analytical Data Interchange Pro-
tocal for Chromatographic Data
1.1 This guide covers the implementation of the Chromato-
2.2 Other Standard:
graphic Data Protocol in analytical software applications.
NetCDF User’s Guide
Implementation of this protocol requires:
1.1.1 Specification E 1947, which contains the full set of
3. Features of the Chromatographic Data Interchange
data definitions. The chromatographic data protocol is not
Implementation Guide
based upon any specific implementation; it is designed to be
3.1 The chromatographic data protocol consists of: (1) the
independent of any particular implementation, so that imple-
data contents (what is being transferred), and (2) the data
mentations can change as technology evolves. The protocol is
container (how it is being transferred).
implemented in stages, to speed its acceptance through actual
3.2 Analytical Information Categories—To make the stan-
use.
dardization process more manageable, five Analytical Informa-
1.1.2 Specification E 1947 contains a full description of the
tion Categories were defined:
contents of the data communications protocol, including the
1. Raw Data
analytical information categories with data elements and their
2. Final Results
attributes for most aspects of chromatographic tests.
3. Full Data Processing Method
1.2 The Analytical Information Categories are a practical 4. Full Chemical Method
5. Good Laboratory Practices Information
convenience for breaking down the standardization process
into smaller, more manageable pieces. It is easier for develop-
3.2.1 This guide covers implementation of Raw Data (Cat-
ers to build consensus and produce working systems based on
egory 1) and Final Results (Category 2). The development
smaller information sets, without the burden and complexity of
committee has completed implementation and testing of infor-
the hundreds of data elements contained in all the categories.
mation in these categories.
The categories also assist vendors and end users in using the
3.3 Chromatography Data Elements—Each data element
guide in their computing environments.
specifies a piece of information that is to be stored or
1.3 The NetCDF Data Interchange System is the container
transferred to another system. A data element has a name, a
used to communicate data between applications in a way that
definition, and may have some default attributes, such as its
is independent of both computer architectures and end-user
datatype, the analytical information category to which it
applications. In essence, it is a special type of application
belongs, and whether it is mandatory or recommended. A data
designed for data interchange.
element may also reference other data elements.
1.4 The Common Data Language (CDL) Template for
3.4 NetCDF Data Interchange System—NetCDF is a data
Chromatography is a language specification of the chromatog-
interchange system designed specifically for the requirements
raphy dataset being interchanged. With the use of the NetCDF
of scientific data. It was developed to meet the requirements of
utilities, this human-readable template can be used to generate
high-performance, large dataset interchange over networks, in
an equivalent binary file and the software subroutine calls
a machine- and network-independent way. NetCDF is imple-
needed for input and output of data in analytical applications.
mented in the portable C programming language, and is made
to be available on all popular scientific computers and operat-
2. Referenced Documents
ing systems. It achieves platform-independence through the
2.1 ASTM Standards:
use of the XDR protocol for byte-stream encoding. XDR
(eXternal Data Representation) was developed by Sun Micro-
systems as part of the Network File System (NFS) and is now
This specification is under the jurisdiction of ASTM CommitteeE01 on
Analytical Chemistry for Metals, Ores and Related Materials and is the direct
responsibility of Subcommittee E01.25 on Laboratory Data Interchange and Annual Book of ASTM Standards,Vol 14.01.
Information Management. Available for Russell K. Rew, Unidata Program Center, University Corporation
Current edition approved April 10, 1998. Published August 1998. for Atomospheric Research, P. O. Box 3000, Boulder, CO 80307-3000.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
E1948–98
in the public domain. NetCDF has a particular advantage over
many other approaches, such as ASCII flat files or structured
ASCII files, because it uses the abstraction of a data access
interface or abstract Application Programming Interface (API).
This API lets the application developer deal with data more in
terms of logical entities, instead of having to think about
specific details of encoding and decoding data. This guide
specifies the use of version 2.0 or later, and the exchange
software should determine only that the version of NetCDF is
version 2.0 or greater.
3.5 Common Data Language—A NetCDF data file has both
binary and human-readable representations. The human-
readable form is an ASCII-encoded file written in the NetCDF
system’s Common Data Language (CDL). CDL is a data
FIG. 1 Usage of NetCDF Utilities
description language, which is a simplified type of program-
ming language without any action statements. The main
gramming Interface (API). These routines are simply cut and
purpose of a data description language is the specification of
pasted into the target application(s). The programmer then uses
data structures. CDL is a generic data description language for
the API to read or write data in NetCDF datasets.
scientific data; it is not application-specific. The basic construct
3.6.3 If FORTRAN is the programming language being
in CDL is that of a multidimensional array, to which many
used, the ncgen utility with the -f option can generate the
types of metadata can be attached. Metadata is additional data
FORTRAN source code wrappers needed to embed the
about the data, that is, attributes about the data that help turn it
NetCDF library code into FORTRAN applications.
into useful information.
3.6.4 Once the application populates the data file with its
3.5.1 For the protocol, a template for chromatography
data, that file can be transferred to another system. If a
written in CDL is supplied to developers. The CDL template
developer or end user needs a human-readable version of the
provides an easily comprehended text version of the structure
binary dataset, the binary file can be fed into the ncdump
and contents of a binary NetCDF file. Developers use this
utility, which regenerates the original CDL source code. The
template with certain NetCDF utilities to generate the software
ncdump utility has an option switch to regenerate the CDL
code (subroutine calls) needed to use the NetCDF toolkit. The
code with or without the actual experimental data. Some
generated code can then be cut and pasted in the end-user
datasets can be enormous and there may be no reason to view
application.
the entire dataset. In this way, data are easily encoded into
3.5.2 For a full description of the Common Data Language,
NetCDF files and the required routines to read and write those
see the NetCDF User’s Guide.
data are incorporated into applications.
3.6 NetCDF Utilities— The NetCDF data interchange sys-
3.6.5 There is another way to build NetCDF data files.
tem has two very powerful utilities called “ncgen” and “nc-
Using the NetCDF Application Programming Interface, it is
dump” that eliminate much work for developers.
possible to build NetCDF binary files one data element at a
3.6.1 After the template for a particular analytical technique
time. However, that method is generally more time-consuming,
dataset (in this case chromatography) is written in CDL, it is
and it is not recommended except for those situations where
fed into ncgen. There are several options with ncgen, the first
applications can fully automate the process.
of which creates the binary file and populates it with fields
4. Chromatographic Data Protocol Distribution Kit
specified by the CDL template. Other ncgen options generate
code for the C language subroutines required for an application
4.1 Information on how to obtain the kit will be posted on
to read and write data in the NetCDF file, and the FORTRAN
the ASTM web site (www.astm.org) under Committee E-49.
wrapper code needed for FORTRAN programs. The ncdump
4.2 The Analytical Data Interchange Protocol for Chromato-
utility reads the binary files generated by ncgen (which were
graphic Data Distribution Kit contains:
then populated by the application using the NetCDF libraries),
4.2.1 Software Disks— NetCDF distribution kit from Uni-
and then generates their ASCII-encoded, human-readable rep-
data (with the modified makefile needed to make the kit
resentation. ncdump is routinely used to check the contents of
compile out of the box), and the Chromatographic Data
NetCDF files, and debug applications that use NetCDF. It can
Protocol CDL Template.
also be used to export data to reporting programs. Fig. 1
4.2.2 NetCDF User’s Guide—supplied by Unidata Program
illustrates the usage of the NetCDF utilities.
Center.
3.6.2 Developers typically start with the CDL source code 4.2.3 Specification E 1947.
4.2.4 Guide E 1948.
description of the data file they wish to interchange. Then the
ncgen utility with the -n option generates the NetCDF binary 4.2.5 Registration Card, used for tracking and user updates.
file. Developers then use ncgen with the -c option to generate
5. Hardware and Software
the C source code needed for the subroutines to read and write
this particular dataset (specified by the CDL template.) These 5.1 This section describes the hardware and software con-
read/write subroutines make up the NetCDF Application Pro- figurations used for testing. In general, the NetCDF system
E1948–98
puts very few requirements on the hardware, because most generate the ASCII representation of the data files, and
routines are left on disk. Only routines being used at any examine it to ensure the data is being correctly put into the file.
particular time are kept in memory. Any limitations found were 6.2 Make Files for NetCDF Libraries and Utilities—In
typically those not imposed by
...