FacsXpert July 8 , 2 0 0 4 7 th I nternational Protg Conference - - PowerPoint PPT Presentation

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

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 instrum ents

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

• f 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
• verw helm s the scientist by exposing the

w hole m odel

FacsXpert required a m odel editor that

• nly 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

Pop up focuses on species class hierarchy starting at Mouse

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

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

• 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)

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

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
• 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:
• by sub classing Darw in class
• G. Support step-w ise debugging

An exam ple of validity checking

Optical detector class contains validity checks such as

– Num ber assigned for a FACS param eter m ust be

• Betw een 1 and the num ber of colors for the

parent FACS configuration

• Unique am ongst sibling optical detectors

– The laser configuration associated w ith a detector m ust also be associated w ith the FACS configuration parent

Checking integrity for param eter num ber value

Protégé form for optical detectors signifies that the user has entered an incorrect parameter number

Checking integrity of Laser configuration relationship

Pick list displays invalid choices as

• disabled. An explanatory tool tip

appears when the mouse is hovered

• ver the disabled item.

W hat are our next steps?

Meet remaining requirements

• H. Represent constraints in m odel

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 L. Have reasoning agents that use com putability, otherw ise prior requirem ent is pie in the sky

Current approach is lim ited:

– H and I are easily achievable, but not J, K and L – At best it w ill becom e hidden plum bing for approach that hits all 1 2 requirem ents

And then there’s the GUI

Protégé has GUI extensibility… but frankly

FACS scientists and the Protégé GUI w ere like oil and w ater

• They w ere confused by the slot buttons w ith + , -, C,V,

X … and they balked at the dialogs

• They begged for a highly custom izable Xcel-like

w idget ( grid) for m anipulating tables of data

• Then, after m any iterations of developing this table

w idget, they ultim ately decided that navigation and group-based m odifications of item s in the table had to be further sim plified.

They w anted to access the table via a tree!

From a table ( linear) view to…

…To a tree ( hierarchical) view

Xpert grid/ table supports

• User custom izability

– Customize column: names, sizes, display order and sort

• rder

– Filter rows

• Persistence of user custom izations

– Automatically remember and use the most recent customizations – Allow the user to save customizations – Allow the user to save and retrieve sets of customizations into property files

• Tree-based read/ w rite access

– Define a tree structure to summarize elements of the underlying table – Select any combination of tree nodes – See the column entries sieved by the node selections – Modify all cells in a column for the sieved rows

GUI extensibility

• Added pick list plug-in fram ew ork
• Added system m enu plug-in and overrides
• Added num erous other slot w idgets