LabAutomation 2006 - SLAS
LabAutomation 2006 - SLAS
LabAutomation 2006 - SLAS
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
MP45<br />
Nahid Jetha<br />
University of British Columbia<br />
Vancouver, Canada<br />
nahid@physics.ubc.ca<br />
Small Volume Liquid Transfer Technology<br />
Where Laboratory Technologies Emerge and Merge<br />
Co-Author(s)<br />
Kurtis Guggenheimer<br />
Andre Marziali<br />
University of British Columbia<br />
High reagent costs associated with molecular biology assays are driving trends toward continued volume reduction and parallelization<br />
of assays. The ability to effectively transfer sub-microlitre sample volumes is therefore critical to ultimately reducing assay costs. The<br />
Sub-microlitre Electrostatic Dispenser (which may be used with any multi or single channel pipettor) enables low volume dispensing from<br />
standard syringe pipettors by applying a potential difference between the target microtiter plate and the pipettor needle, thus subjecting the<br />
fluid to an electrostatic force that aids transfer to the plate.<br />
The parallelization of assays is accomplished through the development of the Ferrofluidic Pipettor. The plunger of conventional pipettors<br />
imparts a large frictional force upon aspirating and dispensing of the sample. These forces prevent the advent of a 96 or 384 channel<br />
hand-held pipettor, which if available would increase the ease and efficiency at which technicians perform experiments. By using a ferrofluid<br />
in replace of the plunger, the hindering frictional forces are drastically reduced and in particular become solely a function of viscosity of the<br />
ferrofluid. As a result the advent of a 96 or 384 channel hand-held pipettor becomes plausible at a drastically reduced cost compared to<br />
conventional 96 or 384 channel robotic pipettor systems.<br />
A description of both the Sub-microlitre Electrostatic Dispenser and Ferrofluidic pipettor will be presented.<br />
MP46<br />
Ronny Jopp<br />
National Institute of Standards and Technology<br />
Mainz, Germany<br />
rjopp@jopper.de<br />
Co-Author(s)<br />
Reinhold Schaefer<br />
University of Applied Sciences, Wiesbaden, Germany<br />
Gary Kramer<br />
National Institute of Standards and Technology<br />
Coding Rules for Construction AnIML Technique Definitions and Extensions<br />
Interchanging data between analytical chemistry instruments, computer applications, and databases has long been hampered by multiple,<br />
incompatible data formats. Modern laboratory management concepts such as electronic laboratory notebooks need simple, common<br />
mechanisms for data storage and exchange. In conjunction with ASTM Subcommittee E13.15 on Analytical Data, we are creating<br />
AnIML (Analytical Information Markup Language) based on XML (Extensible Markup Language) to provide a standard interchange and<br />
storage scheme for analytical chemistry data and its associated “scientific metadata.” The basis for AnIML is its core schema capable of<br />
representing any type of data. The AnIML core schema by itself is not useful as a standard, since it provides myriad ways to record data. To<br />
constrain the representation of data in an analytical genre, we have created extensible “Technique Definitions” that describe how data are<br />
customarily represented in that analytical specialty. Where consensus can be achieved, a Technique Definition can be standardized. Other<br />
areas of the Technique Definition where common agreement is elusive can be handled by vendor-or user-defined “Technique Extensions.”<br />
XML-based applications are accommodating of “extra” information, so while the items provided in a Technique Extension may not be useful<br />
to software that doesn’t know about them, their presence does not break anything. To facilitate the development of parsers to handle<br />
AnIML files, it is desirable that creators of technique-specific Technique Definitions and Extensions follow some general coding rules. This<br />
presentation will describe how Technique Definitions and Extensions are built and the general coding rules for their construction<br />
125