Get documents about "ASTM E13.15 Virtual Meeting 3 March 2005
Document Sample
Address 100 Barr Harbor Drive Phone 610.832.9500
PO Box C700 Fax 610.832.9555
W. Conshohocken, PA e-mail service@astm.org
19428-2959 | USA Web www.astm.org
Committee E13 on MOLECULAR SPECTROSCOPY AND CHROMATOGRAPHY
Minutes for E13.15 Subcommittee Working Group
10:40 am – 12:23 pm EST
Friday, April 1, 2005
Virtual Meeting
I. Introductions and Welcome: Gary Kramer, NIST, E13.15 Chair at 10:30 am EST
II. Review of Agenda. The agenda was approved as circulated. Four sets of minutes from the previous
meetings had been circulated via email – the December 16, 2004 virtual meeting, the February 28, 2005
business meeting at Pittcon, the March 2 working group meeting at Pittcon, and the March 18, 2005
virtual meeting. These minutes were approved to mount on the web site.
III. Attendees:
Michael Boruta, ACD Dave Martinsen, ACS
Mark Bean, GSK Mark Mullins, SSI
Mohan Cashyap, GSK Alex Mutin, Shimadzu
Jamie Duckworth, ThermoElectron Anh Dao Nguyen, NIST
Maren Fiege, Waters Burkhard Shäfer, Univ. Kaiserlautern
Gary Kramer, NIST Carolyn Sheahan, ASTM
Richard Larsen, Jasco Thomas Weber, Waters
Peter Linstrom, NIST
IV. AnIML Website Redesign. Dave Martinsen and Mark Bean presented the draft of the new AnIML web
site, which is a modification of an earlier draft prepared by Mark Bean and Randy Julian. The draft
design consists of a set of frames with graphic navigation icons on the right side, and content on the left
side. The draft can be viewed http://www.candisource.net/animl. A number of comments were made on
the draft. These included:
- Meeting presentations should be included under meetings
- Presentations at meetings such as Pittcon and EAS could go under documentation
- There should be a link for tools to process/view AnIML files
- Additional links in the navigation frame, for things like the sourceforge site, the current
schema, the development schema, etc. could make it easier to get to things with one click, but
the navigation frame could get too cluttered.
Another draft will be presented at the next virtual meeting scheduled for April 15, 2005.
V. Formal AnIML Requirements Document. Gary Kramer found the notes from the original formation
meeting at Shimadzu, September, 2002, and sent the digital files to Mark Bean and Alex Mutin. Mark
transcribed to a Word document, and sent it to Alex. He also created a formal requirements template and
sent that to Gary and Alex. Alex has reviewed the document, and started to organize the information,
but has not yet put it into Mark’s template. Mark will put the transcribed notes from Shimadzu on the
AnIML website.
It was noted that in order to continue in a logical fashion, the formal requirements document needs to be
completed soon. Burkhard noted that if it is not already there, one requirement should be that AnIML
does not become obsolete when new analytical techniques are developed. For example, 96 well plate
readers (which are different from techniques), new types of spectroscopy (which are new techniques),
etc.
Mark Bean made a presentation covering some of the main points in the Shimadzu notes. He noted the
following AnIML requirements:
• Flexible yet highly constrained
• Simple to understand and implement
• Extensible by committee, vendors, organizations
• Human readable (or at least navigable)
• Authenticity can be verified
• Conformance can be validated
Peter Linstrom noted that another requirement is long-term maintainability. This should be added as a
design requirement. Gary commented that AnIML was originally created as a data interchange format,
but that data archiving had been added. Mark noted that data interchange and data archive were there
from the start. We now need to review those original requirements and make sure everyone still agrees.
Other comments to consider in the formal requirements document:
- If we develop a robust core, it implies that AnIML will still be viable 10 years from now. But
do we need to be aiming for 65 years the requirement? Viability doesn’t mean that it needs to
be usable in it’s current form, but should be an easily convertible form.
- Why not assume the format should still be usable? Because if we started this process 10 years
ago, we wouldn’t even be considering XML. Ten years from now, there may be another
specification which supersedes XML. We should be able to convert to that new format.
- XML is syntax. If the data model is sufficiently robust, it should be possible to define a
mapping to any new format. If we have a lot of free-text fields, such a mapping will be more
difficult. Therefore, semantics, a data dictionary, and a way to confirm conformance are
critical.
- The vendor and user extensions are also important, and they need to be done in such a way to
include semantics, a data dictionary, and conformance.
The plan is to take the transcribed lists from the Shimadzu meeting, convert into a formal requirements
document, circulate to 2-3 people, and have ready to send to the group for the next virtual meeting.
Maren will not be able to review because of other commitments, but Mark Mullins and Burkhard will be
able to review. Mohan will also review the draft. Gary will add a review of this document to the agenda
for the next virtual meeting.
VI. Scope and Proposed TOC for Developer/User AnIML Documentation. Burkhard made a
presentation of his ideas for developer and user documentation for AnIML. Each section will start with
an executive summary and philosophy, then go into the details. The proposed TOC for the
documentation is included in the Appendix.
The discussion of documentation led to a number of other issues:
- There should be guidance on when audit trails and digital signatures should be used, and how
to implement them.
- There is nothing in the proposal about modules. Modules are mechanisms for extending the
sample definition, which allow the technique definitions to use the same code. If not for
modules, each technique would need to be modified to introduce the exact same extensions.
With modules, the extensions would need to be defined only once, rather than once per
technique. It is similar to a macro. It’s a way to include common sample parameters which are
not technique dependent. There may be some consequences with implementing this concept. If
the technique definition is no longer a single file, there may be problems. The core group
needs to discuss this further.
- How does this document compare with ASTM styles? Not at all. The content of this document
will end up being included in several ASTM documents. Also, when creating ASTM
documentation, there are strict requirements for referencing previous standards. This
documentation will contain much of what is needed for ASTM documentation. Carolyn noted
that there is much latitude for a practice or a guide. Only three sections are needed: the scope,
significance and use, and keywords.1 In terms of formatting, editors at ASTM will work with
the author to get it into the correct form. Mark Bean noted that he produced a first pass at
ASTM standard documentation five months ago, based on the core and technique schemas at
that time. It was agreed to move forward with the documentation as Burkhard proposes, and
then convert to ASTM style later on.
- How should new techniques be defined and or introduced? This is a policy issue, which is
perhaps not appropriate for the documentation. But doesn’t the procedure for new techniques
still need to be done under the ASTM rules? Note that for a technique to be “standardized” by
ASTM, it could be done at the 5-year review period for AnIML, once it’s approved. But a new
technique could be proposed and balloted at any time. So a new technique could be added as a
revision, and there is a process defined for that to happen.
- There are some issues, however. The committee and ASTM don’t always have the domain
expertise. For example, MS is a domain which is represented by ASMS, but is not part of
ASTM. ASMS wants to help, but doesn’t want to be a standards body.
VII. Action Plan.
- There will be a second virtual meeting series set up for the core group. Carolyn Sheahan will
set these up on the Fridays which the main group is not meeting. Participation will be limited
to the core group members designated at Pittcon, plus Anh Dao.
- Tools which have already been developed should be posted to SourceForge, along with
Readme files explaining what the tool does, what version of AnIML it works with, and how to
install and run it.
- At Pittocn, Jamie contacted several vendors to get exports of metadata. Who should these be
sent to? Richard Larson can also get screen shots from several vendor’s software. These
should be sent to Gary.
1
During the meeting, Carolyn stated that there were two mandatory sections. However, she later corrected this to indicate the
three required sections. The ASTM website contains information on the ASTM documentation requirements:
http://www.astm.org/COMMIT/Blue_Book.pdf
- Should there be a face-to-face meeting of the Working Group in Philadelphia in May? This
could be at ASTM, or GSK would be willing to host. It was decided to wait for the next virtual
meetings, and decide then if a physical meeting would be useful.
VIII. Agenda Items for Next Virtual Meeting.
- Deferred Agenda Items. Two items for today’s agenda – Handling the Results from Multiple
Analyses and Handling Results from Hyphenated Techniques can not be discussed today
because of time limitations. There are policy issues which must be addressed for these topics
which can’t be handled by the core group alone. These will be put on the agenda for the early
part of the next virtual meetings. The “Multiple Analyses “ topic will be given ½ hour at the
April 15, 2005 meeting, and “Hypenated Techniques” will be given ½ hour at the April 29,
2005 meeting.
- Website redesign
- Review of formal AnIML requirements document
IX. Action Items:
Web page subgroup: Dave Martinsen, Mark Bean, Burkhard Shäfer – redesign of AnIML web
site, 2nd draft
Mark Bean, Alex Mutin – complete formal requirements document, circulate prior to next virtual
meeting
Core Group – virtual meeting on April 8, 2005
Tool developers – post tools and documentation on sourceforge
Jamie Duckworth and Richard Larsen – send vendor metadata details to Gary
X. Future Meetings:
Working Group Teleconferences
April 15, 2005, 10:30 am – 12:30 pm EDT
April 29, 2005, 10:30 am – 12:30 pm EDT
Business Meeting: EAS, November 14-17, 2005, Somerset, NJ
Business Meeting: PittCon, March 12-17, 2006, Orlando, FL
XI. Adjournment
Motion. Second. Carried unanimously at 12:23 pm EST, at which time the virtual meeting
evaporated.
Submitted by David Martinsen, ACS, ASTM E13.15 Secretary
APPENDIX: Scope and Structure of AnIML Documentation
Burkhard A. Schäfer
b_schae@users.sourceforge.net
- 1st Draft, 04/01/2005 -
Introduction
The document to be produced should serve two audiences:
Decision makers in the user and vendor community considering the adoption of AnIML as a data
format
Developers in the vendor community and interested scientists who develop software to read and write
AnIML documents
To cater to both audience groups, the document will describe both the philosophy of the AnIML approach
and the actual implementation. Each section starts with a high-level description of the issue at hand so
that readers can get a quick overview of what a certain AnIML feature is intended for.
In a second stage, the document can be used to create the needed ASTM documents.
Document Structure
1. Introduction – What is AnIML all about?
2. AnIML Architecture
2.1. Core = Generic data container
2.2. Technique Definitions = Meta data dictionary
2.3. Extensions = Vendor/user/site-specific amendments
3. The AnIML Core
3.1. Structure of an AnIML file
3.2. Sample information
3.2.1. Parameter Categories and Parameters
3.3. Experiment Steps
3.3.1. Definition
3.3.2. Samples consumed and produced
3.3.3. Method information and measured information
3.3.3.1. Experiment Step Parameters
3.3.3.2. Pages
3.3.4. Raw Data Encoding
3.3.4.1. Parameter Categories and Parameters
3.3.4.2. Vectors
3.3.4.2.1. IndividualValueSet
3.3.4.2.2. AutoIncrementedValueSet
3.3.4.2.3. EncodedValueSet (base64)
3.3.4.3. Data types
3.3.4.4. Units
3.3.5. Page Nesting
3.3.5.1. Semantics
3.3.5.2. References
3.4. Experiment Step Nesting
3.4.1. Introduction
3.4.2. Semantics
3.4.3. References
3.5. Templates
3.5.1. Creating a Template
3.5.2. Applying a Template
3.5.3. Template semantics
3.6. Audit Trail
3.6.1. Introduction
3.6.2. Structure of an Audit Trail entry
3.6.3. Creating Audit Trail entries
3.6.4. Examples
3.7. Digital Signatures
3.7.1. Introduction
3.7.2. Signable Items
3.7.3. XML DSIG usage in AnIML
3.7.4. Creating a Signature
4. AnIML Technique Mechanism
4.1. Introduction
4.2. Technique Definitions
4.2.1. Introduction and Definition
4.2.2. Technique Definition file structure
4.2.3. Applying a Technique Definition to an Experiment Step
4.3. Technique Extensions
4.3.1. Introduction and Definition
4.3.2. Extension file structure
4.3.3. Extension semantics
4.3.4. Applying an Extension to an Experiment Step
4.3.5. Applying multiple Extensions to an Experiment Step
4.4. Valid Documents
4.4.1. Validation criteria
4.4.2. Document validation options
5. Usage guidelines
5.1. Single experiment step
5.2. Multiple sequential experiment steps
5.3. Single-detector experiment
5.4. Multi-detector experiment
5.5. Sample preparation
5.6. Complex workflows
6. Summary
7. Glossary
