Sabatini Lab DataJoint Workflow

What This System Was

The public bernardosabatinilab/sabatini-datajoint-pipeline repository is a Sabatini Lab DataJoint workflow. The repo documents a Python 3.9 environment, editable package installation, Jupyter usage, DataJoint database configuration, Docker-based local SciViz testing, and an expected Inbox-style data layout for lab sessions.

This is a better way to describe the system than the older generic copy on this site. The public repo supports a concrete claim: this was a lab workflow for organizing and working with multimodal neuroscience data in DataJoint, with session directories that can include Imaging, Photometry, Behavior, Ephys, and DLC behavior videos.

Publicly Confirmed Workflow Shape

The repository README defines a subject/session folder structure with multiple optional modalities:

• Imaging data, including ScanImage-style TIFF stacks
• Photometry data, including .mat, .tdt, and TOML metadata files
• Behavior data, including TOML metadata plus parquet or CSV files
• Ephys data, including .bin, .lf, and .meta files
• DeepLabCut behavior videos stored as .avi
• DLC project directories kept at the Inbox level

The repo also includes:

• A workflow package for DataJoint-style pipeline code
• notebooks for interactive scientific use
• docs for project documentation
• tests for validation
• webapps/sciviz for local SciViz testing through Docker Compose
• environment and setup files for reproducible local installation

My Role

My contribution should be understood as DataJoint deployment and operations support rather than a vague claim of owning every part of the scientific pipeline. The work sat at the interface between lab data conventions, DataJoint schema-backed workflows, local scientific notebooks, database configuration, and visualization/testing surfaces.

That kind of work is practical and high-context: you have to understand how scientists actually store sessions, how acquisition systems produce files, how DataJoint expects relational dependencies to be expressed, and how to make the whole thing usable by a lab without turning every analysis into an infrastructure project.

Why It Matters

This system is a good example of the type of software work I enjoy: taking real experimental messiness and giving it a structure that scientists can trust.

The important engineering problem is not only "process a file." It is:

• Preserve the relationship between subject, session, modality, and analysis artifact
• Make derived data traceable back to raw acquisition
• Keep notebook workflows close enough to scientists to remain useful
• Provide testing and local visualization surfaces for iteration
• Respect the lab's existing file organization instead of pretending every lab starts from a perfect data model

What This Shows About My Work

This record belongs on the deployed systems page because it represents scientific infrastructure in the real world: public code, lab-specific conventions, database-backed workflow structure, and enough operational detail to make a research workflow run outside a toy example.

It also shows a pattern that runs through my work: I like systems where software is the translator between instruments, data, researchers, and interpretation.