FacsXpert July 8 , 2 0 0 4 7 th I nternational Protégé Conference • Builds protocols for studies w ith FACS instrum ents • Uses a m odified Protégé-based architecture that prom otes runtim e extensibility for the end-user
FacsXpert • Built – At Stanford University’s Herzenberg Lab – I n close collaboration w ith Lee Herzenberg, Jam es Tung, David Parks, W ayne Moore and other researchers in the Herzenberg Laboratory • W ith help from – Mark Musen, Ray Fergerson, Monica Crubezy, Natasha Noy and the Protégé com m unity
FacsXpert • Presented by – Stephen Meehan, softw are engineer Herzenberg Lab, Stanford University m eehan@darw in.stanford.edu – Since 1 9 9 2 , Stephen has pursued a “dream ” of a “softw are dem ocracy” architecture w here: • An application derives the m ajority of its behavior from runtim e interpretation of its UML design m odel • A user can extend this m odel w hile the application runs Thus the m odel is m ore than a design artifact, it is runtim e governm ent by the people … for the people
Scope of Presentation 1 . The FACS dom ain and need for runtim e extensibility 2 . FacsXpert’s approach to data structure extensibility 3 . FacsXpert’s approach to data integrity extensibility 4 . FacsXpert’s approach to GUI extensibility
FACS instrum ents Count and characterize fluorescent- labeled cells in suspension to – Monitor the progress of HI V infections by counting the num ber of CD4 T lym phocytes in blood from HI V-infected people – Classify and stage tum ors and to m onitor bone m arrow transplant survival – Do the basic science and studies that underlie all these clinical advances
FACS protocols specify w hat w ill be done in a FACS assay For each tube in the assay – Add up to 2 0 reagents, each linked to one of 1 2 fluorescent dyes Add one cell sam ple of up to 5 m illion cells – I ncubate and analyze w ith a m ulti-laser – ( Hi-D) FACS instrum ent – Store the resulting data file ( often about 5 m egabytes) One assay often has 6 0 or m ore tubes
Sophisticated softw are is needed • Must com pute a feasible com bination of staining reagents ( w hich “label” cells) by taking into consideration: Targeted species – – Targeted cellular m arkers – Highly variable optical characteristics of fluorescent elem ents Optical detection capabilities of a FACS instrum ent’s – configuration – Fluorescence interference betw een fluorescent elem ents Purpose of cell labeling: to gate, dum p or discover cell – populations Availability of inventory – – Bio-chem ical affinities betw een staining steps
Sophisticated softw are is needed • Pipetting guide’s – Reagent and specim en am ounts m ust follow highly variable dilution recom m endations – Organization m ust cater to pipetting technician w ork flow w hich differs from the planning w ork flow of the scientist Final protocol know ledge m ust interoperate w ith • – I nstrum ent softw are ( offline as w ell as real tim e) – Analysis softw are • GUI for decision m aking m ust be highly intuitive Senior FACS scientists are often som ew here betw een com puter naïve and totally com puter-phobic
Highly extensible softw are is needed • FACS vocabulary and “best practices” are – Minim ally standardized – Rapidly changing • From day to day, FACS scientists cannot predict – W hat questions they w ill be asking – W hat m aterials they w ill be w orking w ith • Hence, their “research planning” softw are applications m ust be highly flexible and custom izable
Highly extensible softw are ( cont.) THUS … scientists ( in addition to know ledge/ softw are • engineers) m ust be able to extend – Data structures ( classes, attributes, etc) – Data integrity ( rules that check know ledge inputs) – The GUI … w ithout crashing the current application or future upgrades!!! Protégé provides the foundation for such a runtim e evolvable • system • Com m ercial alternatives ( e.g. Oracle, Rational Rose) suffer from higher financial cost, higher sys adm in cost, closed source and design-tim e centricity
Data structure extensibility • Protégé supports data structure extensibility through object-oriented sub classing • How ever, the its m odel editor GUI overw helm s the scientist by exposing the w hole m odel FacsXpert required a m odel editor that only focuses on a specific part of the m odel at the specific tim e that it is relevant to the application
FacsXpert solution for data structure extensibility A class-type slot widget that supports a create action which limits the model editor’s focus to the slot’s allowed parents User creates 1 direct and 2 indirect Mouse sub classes Pop up focuses on species class hierarchy starting at Mouse
FacsXpert solution for data structure extensibility • A sm all # of program m ing idiom s ready FacsXpert for such extensions; for exam ple: – Creating instances myProject.createInstance( null, DisplayUtilities.pickCls( null, Collections.singletonList( designTimeLeafClass ))) – Querying class type designTimeLeafClass .equals( unknownClass ) || unknownClass .hasSuperclass( designTimeLeafClass )
I nstantiating a new subject The program m ing idiom detects the need to query for sub classes to the m ouse class End user’s extended attributes automatically appear
Darw in “crash-proofs” data structure extensibility W e built a tool nam ed Darw in that guards m odel evolution by handling m odel editions w hich break hard-coded expectations • For any given class, Darw in prevents the “extinction” of one or m ore slot associations and one or m ore slot facets • One can set 1 of 2 “w atch dogs” to m onitor changes to “endangered” m odel elem ents: – Golden retriever barks w hen user changes such an elem ent and allow s rollback ( for engineers) – Doberm an Pincher prevents user from m aking the change ( for end-users)
Darw in’s JAVA generator Darw in generates JAVA m odules that benefit client • code by – Establishing a sim ple and consistent idiom for type- safe access to the endangered portions of the Protégé m odel – Adding JAVA com piler checking as a m eans of tracking m odel dependencies Darw in translates • – All Protégé classes into JAVA interfaces hence supporting m ultiple inheritance – Concrete Protégé classes into JAVA classes that im plem ent all associated JAVA interfaces
From Protégé class… The class “FACS single-reagent proposal” has two direct super classes
… To JAVA Protégé super classes become JAVA super- interfaces Protégé leaf classes become JAVA interfaces Protégé concrete class becomes a JAVA class that implements all of the interfaces
Data integrity extensibility Prim ary goal – Runtim e extensibility of constraints that check know ledge inputs ( hereafter checks) . Know n to the Protégé com m unity as “know ledge acquisition” Out of scope – Runtim e extensibility of constraints that infer new know ledge • • validate ontologies ( consistency checking, disjointedness, sem antic im balance etc.) I n practical term s… – Allow scientists to author and authorize checks w hile FacsXpert runs
Requirem ents A. Decouple check inquirers from check providers B. Support reuse for both of the above actors: A. I nquirer: “I s anything w rong?” B. Provider: A. Dom ain independent B. Param eter-izable check or check tem plate; user com pletes param eters w hen “binding” C. Make checks m odel associated and oriented D. I ntegrate checks w ith Protégé form s & pick lists
Requirem ents E. Make checks scaleable A. Focus on lim ited instance context B. I ncrem ental execution F. Stay in sync w ith m odel re-factoring G. Support stepw ise debugging H. Represent constraints in m odel A. Start at :CONSTRAI NT super class B. Support inquirer querying of characterizations such as: advisory, w arning, error and fatal
Requirem ents I . Allow user to add checks w hile FacsXpert runs J. Support end user, ad hoc check authoring K. Allow com putability of dependencies, conflicts & bottlenecks A. Prevent conflicts betw een checks B. Prevent conflicts betw een checks and m odel facets and onto-clean m eta classes/ slots L. Have reasoning agents that use com putability (otherwise prior requirement is “pie in the sky”)
Data integrity extensibility Engineering options ( in 2 0 0 2 ) 1 . Reuse an existing runtim e com putable gram m ar � Pal w ith EzPAL � JESS � OCL 2 . I nvent a new “non program m atic” gram m ar; im plem entation options included: 1 . Translate invented gram m ar to accepted gram m ar to reuse interpreter 2 . I nterpret the invented gram m ar directly 3 . New JAVA validity checking fram ew ork that prom otes “param eterized check tem plates”
W e took choice 3 … and met 7 of 12 requirements � A. Decouple check inquirers from check providers � B. Support reuse in both of the above actors � C. Make checks m odel associated and oriented o By sub classing Darw in � D. I ntegrate checks w ith Protégé form s & pick lists � E. Make checks scaleable � F. Stay in sync w ith m odel re-factoring: o by sub classing Darw in class � G. Support step-w ise debugging
More recommend
