Our previous post (The Digital Lab Needs an Intermediate Data Schema (IDS): a First Principle Analysis) has established the need for an intermediate data file format for Digital Labs and explains why we chose JSON + Parquet. Now let’s dive deeper into its use cases and discuss what an IDS is intended for, and what it’s not intended for.
In a nutshell, think about your lab as a big warehouse, where there are multiple parcels of different content, shape, weight, and color (like the data produced by your lab instruments, their software, your CRO/CDMOs, and other data sources). Because these parcels are heavily packaged in their own unique way, when you have too many parcels, it’s really difficult to find the ones you need. You can't compare the content within each of these parcels, or make any meaningful observation beyond “these are all very different things.”
Now imagine, each parcel has a sidekick called IDS, attached to each cardboard box, describing the parcel’s content in a consistent manner. With IDS, it would be much easier to find what you need, since you do not need to unpack each parcel and you can just search through the sidekick.
You can also leverage the sidekick's content consistency to compare different parcels; for example:
Hopefully the analogy above is helpful. Now let's move from physical packages in a warehouse to data "packages" in a life sciences company. In more technical terms, IDS is a vendor-agnostic, data science-friendly file format that captures all the scientifically meaningful and data science-relevant information from the vendor-specific or vendor-proprietary file formats produced by a fragmented lab data source ecosystem.
IDS serves multiple important functions: data search, data flow/liquidity and data analytics, which we'll discuss a bit below.
With an IDS, data scientists can leverage API-based or full text search, enabling them to quickly locate an instrument RAW file. As with the package analogy, all data fields are acquired and indexed.
Data can now flow to third-party systems without requiring each of these systems to parse the vendor-specific file formats. This fundamentally breaks down internal data silos and enables more seamless information sharing among instruments, informatic applications, analytics tools and contract organizations (CRO/CDMOs).
The majority of existing lab informatics software solutions were designed as Windows-based on-premises applications. For example, in order to analyze Mass Spec data, a scientist would drag and drop 20-100 RAW files into their favorite analysis software program, spend hours processing the data, and generate a report. This workflow unnecessarily consumes time, and limits the potential for data reuse and sharing.
Now, imagine you need to analyze data using big data technologies like Hadoop, Spark, or others. You wouldn’t be able to effectively use those big data tools while manually managing RAW files. However, IDS (JSON + Parquet) makes big data analytics possible, and the Tetra Data Platform will store, partition and index the IDS files in anticipation of such use cases.
Not at all. IDS is not a replacement of the vendor-specific formats. Organizations need always to save these RAW files, such that scientists can:
IDS makes it easier to find the RAW file and provides large-scale data analysis much efficiently since the RAW file does not need to be opened. Just like the Parcel and Sidekick analogy, the sidekick is not meant to replace the parcel; only to improve its use. In fact, the Tetra Data Platform will first ingest RAW data and then trigger RAW to IDS conversion or harmonization using data pipelines.
This is essentially a variation of the question above, but usually asked in the context of experimental data management.
Let’s first define “archive.” In the context of experimental R&D data, an instrument typically produces “RAW” data - the points, ramps, intensities, depths, counts, and response factors produced by the detector or sensor - which is processed by instrument control/analysis software to produce “Analysis Result." Since sometimes the “Analysis Result” is saved in the same “RAW” file; for the purpose of this article we'll call this RAW data. RAW data is most often present in a vendor-specific format, vendor proprietary format, or non-file-based data system.
Archive of RAW data means creating a backup from the instrument software or analysis software as a file, stashing it somewhere, and then, when needed, restoring back to the original system, as if the data has never left the source system. (AWS S3 Glacier deep archive is a popular, secure, durable, and extremely low-cost Amazon S3 cloud storage service for data archiving and long-term backup).
Thus, the answer is: No, IDS itself isn't intended for long-term archival.
In most cases, it’s not possible to convert a vendor-proprietary and often binary format into JSON and Parquet, and then be able to re-import the data into the source system without loss of information.
However, the goal of IDS is not to capture everything possible in the RAW file, and in this sense it’s lossy. Therefore, IDS files alone are not sufficient to fulfill experimental data archival requirements. However, as described in the previous section, the content in IDS files will serve as an abstraction layer that will greatly augment search, liquidity, and analytics.
Do not get us wrong, we believe data archival is extremely important. GXP Compliance, patient safety, plumbing "dark data" for new insights: in these use cases and more, data archival critically impacts scientific success. The Tetra Data Platform (TDP) archives original instrument RAW files to the cloud with full traceability and data integrity. You can easily restore processed versions and track lineage back to the original instrument or instrument software.
On top of this, having IDS as a harmonization layer makes the archived data much easier to locate and the information stored in these RAW files much more easily accessible. Vendor and third-party binaries can be searched by file name or extension, but TDP's IDS enables users to search on granular fields like experiment ID, user name, method parameter, or instrument serial number; everything is indexed for faster and easier discovery.
For example, take a look at our Empower Cloud Archival App that leverages IDS to help you search your Waters Empower projects archived in Tetra Data Platform:
Hopefully we've helped you understand what happens to your irreplaceable RAW files (we save them!) and how IDS can lead better analytics, facile search, and ready indexing. In other words, IDS provides everything you'll need to track, find, and sort the heterogeneous and invaluable “packages” in your R&D data warehouse.
If you’d like to dive deeper into the Tetra Data Platform, we recommend this whitepaper covering many of its key capabilities.
As always, follow TetraScience for ongoing updates on experimental R&D data and related topics: