- 1 Overview
- 2 Specific goals for this deliverable
- 3 Strategy for achieving objectives
- 4 Relationship to other goals of the working group
For computer programs to exchange data transparently requires standardized serialization schemes. Traditionally this means having a standard file format for data exchange. Supporting such standards may include such things as clarifying or extending an existing standard, providing users and developers with software tools to use the standard, providing conversion between formats, and ensuring an upward conversion path to the next standard.
How can we increase interoperability by supporting current standards?
The place to begin is by identifying current standards and assessing available support. Current standards include file formats like NEXUS, MEGA, and PHYLIP described on the Molecular Evolution Workshop page at Woods Hole. To what extent can these formats be validated? To what extent is the choice of format an irrelevant, transparent issue for the user who wishes to view, query, store, edit or analyze data?
Consider the simplest format, FASTA. We can view the data in a FASTA file using a standard text browser or word processor. Yet, how many computer programs that input FASTA files place an arbitrary limit on the length of a definition line? What about support for search, query, and edit operations? Even for a simple FASTA file, the possibility of arbitrary line breaks means that when we search for the sequence GAATTC using a standard text editor, we may fail to find it because the pattern is hard-wrapped from one line to the next. Without this kind of query capability, automatic editing is not possible.
The problem becomes much worse when we consider other file formats. For instance, PHYLIP files limit OTU names to 10 characters. In a NEXUS file, an OTU can be referred to by an identifier string called a "taxon label", or by a whole number that corresponds to the order in which an OTU was declared. This means that, if we wish to rename OTUs in a NEXUS file in order to achieve compatibility with PHYLIP limits, we cannot simply do a search-and-replace using the taxon label, because an OTU might be referenced by a number instead of a label. Clearly, then, in order to support these standards and hide the details of file formats from the user, we must have things like wrappers for PHYLIP programs that preserve long names, and editors for NEXUS that are aware of NEXUS semantics.
Also, it may be clear from these examples that we can neither assess nor enhance support for standards without understanding the goals and practices of the user community.
Specific goals for this deliverable
Assessment of current user practices (Sudhir)
Statement of problem: To develop support efficiently (applying the 80:20 rule), we need to know what most users are doing, and how they are doing it.
Approach: Use analyses of literature citations and inspection of software packates to determine the most common input and output formats and the most common operations.
- include numerical analysis of citations to different packages
- make a table of input and output formats used by common packages
- optionally, consider some additional questions
- how do users create data files?
- how do users edit data files? what are the most common edits (e.g., delete OTU)?
- do users archive data in a retrievable manner and, if so, how?
- what "dead-end" files are created?
- how do users visualize data in files?
- how do users query data in files?
Note that some parts of this will cross-fertilize with the goal of assembling a library of cases. While pursuing this goal, we can identify use cases and users who would be willing to contribute files.
Collection of examples of NEXUS flavors and pathologies (Mark)
Statement of problem: To develop support for NEXUS we need examples of different versions as well as pathologies.
Approach: Collect examples and link them to this page. See Supporting_NEXUS_Documentation for an example of how to do this.
Collection of other file format examples (Enrico, Sudhir, others)
Statement of problem: To do practical work in this area (generating validation and transformation servers), we need to have sample files.
Approach: Collect examples and link them to this page. Ideally these will be actual user files, but they also could be hypothetical tests files that represent specific challenges. Eventually create a more formal library of cases.
- Create a list of formats
- Generate a table for each type of format. See Supporting_NEXUS_Documentation for an example of how to create a wiki table for this.
- Populate the tables with examples of each type of format
- Examples of formating errors (format does not fit nominal standard) and parsing errors errors (parser chokes on valid files) A list of existing formatting/parsing errors
Formalization (Gopal, Enrico)
Statement of problem: To support current standards by providing validation, interconversion, and storage, we need to define these standards precisely.
Approach: Develop formal grammars, evaluate them using DCG processing on test files. Consider best practices to deal with information loss.
- table with grammars for NEXUS, MEGA, PHYLIP, DAMBE, ...
- table with test results for each grammar
- recommended practices for dealing with information loss
Strategy for achieving objectives
The strategy for undertaking these tasks corresponds to the agenda for our first meeting. After some initial discussion in which we may redefine or supplement the four goals above, we will break out into goal-specific groups or task-forces. Over the next two days, each task-force will work on their corresponding goal, and will occasionally report to the group as a whole. Hopefully the task forces will interact with each other appropriately to share resources and to get feedback.
Relationship to other goals of the working group
Purposefully, we are approaching the Current Standards goal in a way that will lead on to our other goals. Formalization will identify minimal elements for both a Database Archive and a Future Data Exchange Standard, and provides an upconversion path to the Future Data Exchange Standard. Assessing user practices will broaden and clarify our awareness of what are the most needed capabilities for a Future Data Exchange Standard and a Database Archive; by clarifying the inputs and outputs used in typical analyses, it provides a foundation for Analysis Templates; it also may reveal Future Challenges. The case library task directly addresses our Library of Cases goal, and provides material for the future goals of Education and Outreach, Support for Evaluation, and Analysis Templates. The software gap analysis task will clarify what is needed in the way of Support for Evaluation and probably will identify numerous Future Challenges.