Transcript Technical Introduction

The CCPN Project
Technical Introduction
Expanded from presentation,
Utrecht Feb. 2007
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
The CCPN Project
• Collaborative Computing Project for NMR
• Started in 1999
• Unifying platform for NMR software
similar to CCP4 for X-ray crystallography
• Community-based, open-source, software
development
Context
High-throughput structural biology relies on
software pipelines. Programs that do
various tasks must be combined,
preferably so that there are alternative
programs for each task. Yet, connecting
one program to another can be quite
difficult in practice. Often all you have is
an incomplete set of partial and badly
maintained conversion scripts.
Task1
Convert
Task2
Convert
Convert
Task1
Native Anarchy
Task3
Disunified Software
• Every program does things its own way.
- proprietary data formats.
• No provision for data exchange.
- limited choice, and data loss.
• No provision for data harvesting.
- lost and neglected data.
• No basis for task or code sharing.
- you must keep re-inventing the wheel.
• Software pipelines require interoperability.
CCPN Activities
• Data standards and software integration
– Data Model with associated subroutine libraries.
– Tools – a framework for data modeling.
– Collaborations
• Software development and distribution
• Meetings and workshops
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
Data standard - objectives
– Lossless data transfer between programs
– Completeness, integrity of data
– Data harvesting
• All data retained till deposition
• Allows data mining
Conversion with Data Standard
Task1
Convert
Task3
Convert
Task2
Data
Standard
Convert
Task1
Convert
Software integration - objectives
• Possible to work between programs
• Link and integrate software
• Allow shared modules
– All data in one shared storage
Runtime storage hub
Task1
Convert
Task3
Convert
Task2
Data
Storage
Convert
Task1
Convert
CCPN focus
• Data creation
rather than querying final results
• Applications
rather than documents
• Information store rather than message passing
• Full details
rather than summaries
• Precise specifications
Framework requirements
• Precisely defined standard
– A single central description
– Validation directly against standard
• Support many parallel implementations
• Ensure data consistency and validity
• Easy to maintain and modify
• Programmer-friendly
Chosen approach
• Model Driven Architecture
• Abstract data model – UML
• No stable format – stable API
– easier to maintain as model changes
• Support XML and SQL, underneath
• Support several programming languages
• Automatic code generation to make it feasible
Preferences
• All science in one, shared multipackage model
made in collaboration.
• API, storage and I/O libraries reflect model
exactly
• CCPN framework provides storage, I/O and
all bookkeeping
• Others do science and user interaction
• Program-specific needs in extensions
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
CCPN code generation
The applications that the user sees remain independent, but do all their
data access through the CCPN APIs. These in turn store and load
the data transparently from disk (XML or database).
All subroutine libraries are generated fully automatically from an
abstract logical model, that describes the structure and
characteristics of the data without reference to the implementation.
The logical model is made in UML from a series of connected
packages, designed by teams of domain specialists for different
scientific domains.
All generated code is by definition consistent, since it derives from the
same model. Code generation is fully automatic, and the resulting
subroutine libraries can be used directly, without manual tweaking.
Implementation-specific code is stored as code snippets in tagged
values inside the UML; it amounts to less than 0.5% (character
count) of the total.
The API implementations are object oriented and are guaranteed to be
stable – unlike the underlying storage formats. Storage is
transparent, and applications should work equally well with either a
file-based or a database implementation. Some features, like
transaction handling, roll-back, or access control, will only be
properly implemented in database implementations.
Code Generation Framework
Software
Developers
Domain
Experts
MEMOPS
framework
Documentation
Handcoded (< 1%)
Autogeneration
UML Model
Package 1
APIs
User
Python
Storage
Deposition
Wrappers
Application
Package 2
Java
C
Perl
SQL
XML
Package 3
CCPN APIs
• Application Programming Interface
– Is the standard
– Subroutine library
– Data accessed in memory
as if stored inside the data model
– Classes and objects, with functions (get, set, …)
• Comes with:
– Integrated, transparent I/O (file or database)
– Complete validity checking
– Protection against casual change
(data encapsulation)
– Versioning and backwards compatibility
Developer Benefits
• Standard shared by many programs
– Comes with reference data
• No need to write I/O or checking code
• Concentrate on the science, not book keeping
• Extendible
– Program-specific data in all objects
– New model packages
• Functionality
– Utility functions (e.g. Molecule from 1-letter codes)
– Notification system (for GUI)
Languages and Formats
Language
Format
Python
XML
SQL
Analysis,
FormatConverter
Java
C
Extend-NMR
Bruker
TopSpin,
NMRVIEW
MSD NMR
database,
BIOXDM ?
PIMS??
BIOXDM ?
EuroCarbDB
For all languages:
• Model description
• Documentation
Processing
Extend-NMR,
EU-NMR,
AUTOPSY,
(Varian)
(CYANA)
Perl
(Bioinformatics)
(Bioinformatics)
For all formats:
• Schemas
• I/O mappings
Implementations marked in pink are available.
API generator architecture
• Reduce burden of adding new languages, formats
– Languages (Python, Java, C, …)
– Storage formats (XML, SQL)
Most of the logic
Language & Format
Independent
(80% of the code)
Format dependent
Language dependent
only
only
Language & Format
dependent
Code required for
Code required for
new format
new language
API functions
•
•
•
•
•
•
•
•
‘get’ and ‘set’ (Attributes and links)
‘add’ and ‘remove’ (Multiple attributes and links)
‘sorted’ (Multiple unordered links)
‘findFirst’ and ‘findAll’ (Multiple links)
– Simple filtering (attribute == value)
create and ‘new’ (Objects)
– Normal and ‘factory function’ object creation
delete (Objects)
– ‘Delete’ function.
checkValid, checkAllValid (Objects)
‘current’ (e.g current NmrProject)
• API classes are strongly coupled. For efficiency reasons
object-to-object links are two-way, with information stored on
both sides, and this forces objects to interact directly with the
internal representations of objects they are linked to.
Code Generation
UML is edited in a commercial editor (ObjectDomain) that
includes a Python scripting environment. An ObjectDomainspecific script extracts the model description into a Python
in-memory representation, that is then written to disk as a
series of XML files. The UML editor is not used further, and
another one could be substituted simply by providing a new
data extraction script.
Subsequent code generation is done outside the editor. The
XML model description is read into memory as a series of
Python objects, based on the Python classes of a
MetaModel. Code generators then uses the information in
the in-memory description to generate all necessary files
Legend:
CCPN code
Off-the-shelf
Application code
files
CCPN generated
Code Generation
edit UML
ObjectDomain
UML data
MetaModel
In-Memory Model
Python objects
On-disk model
XML file
Autogeneration
API code
Schemas
Mappings
etc.
Generation:
CCPN Python generators
Auxiliary:
CVS/SVN, Ant, Eclipse
Runtime implementations
File and database implementations are
organised differently, with varying use of
off-the-shelf code. For both
implementations a large fraction of eth API
code is taken up by constraint checking, to
make sure that data remain consistent
with the rules embedded in the model.
Legend:
CCPN code
Off-the-shelf
Application code
files
Runtime Python XML Application
CCPN generated
Science code
User Interface
User application
Utility functions
Python API
Data get, set.
Validity check
XML parser
XML I/O mappings
What to do for
which element
XML I/O code
Generic XML read/write
Data Storage
XML files
User data in
CCPN XML format
Legend:
CCPN code
Off-the-shelf
Application code
files
Runtime Java SQL Application
CCPN generated
Science code
User Interface
User application
PIMS: Servlets, JSP (JSF)
Utility functions
PIMS: Backing beans, JSF
Presentation layer
Commit, input check
Java API
Data get, set.
Validity check
Hibernate mappings
Hibernate
Object-DB synchronisation
Database Schema
Database
User data in database
Client/Server ?
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
Model requirements
• Comprehensive
– Contains all data you need to run an application
– Final and intermediate results
• General
– can handle all likely ways of working
• Unequivocal
– Normalised - data stored only once
– Data stored in one way, std. units, …
• Unavoidably complex
Data Model Coverage
Specific
Programs
UTILITY
Citations
Annotation
Classifications
Nuclei and
Isotopes
People
Access
Control
Organisms,
Taxonomy
LIMS
NMR
Samples
MOLECULE
Molecule
Description
Residue
Template
Molecular
System
Preparation
Experiments
Structure and
Coordinates
X-RAY CRYSTALLOGRAPHY
Beamlines
Crystallisation
Structure
Targets
Project
Tracking
CCPN Packages
• Grouping – model, code and data
– e.g. NMR, X-ray, Molecular description
Molecule
• Package ‘import’
– e.g. Coordinates loads MolSystem
information
ChemComp
People
MolSystem
• Allows lazy loading
– Only load relevant data, code.
– Load on demand
Nucleus
Sample
Coordinates
• Different groups can ‘own’ different packages
– New domains – new collaborators
Nmr
Main Concepts
• Model is Normalised
– Every piece of information stored in only one place
• Classes and Objects
– Inheritance and subtypes (single inheritance only)
– Elements (attributes and links) and operations
Most operations not entered explicitly
– Classes may be abstract
• Attributes
– String, numeric, special complex types
– Compare by value
•
Links
–
–
–
–
Connection to other objects
Generally two-way
All objects have identity
Most –to-many links are sets
Example: ChemComp
ChemComp
1
ChemCompVar
*
*
LinkEnd
+linkCode: Word
*
+boundLinkEnd
+boundLinkEnds
1
+boundLinkAtom
LinkAtom
+elementSymbol: Word
+linking: ChemCompLinking
* +descriptor: Line
+isDefaultVar: Boolean = False
+name: Text
+varName: Text
+msdCode: TwelveLetterCode
+varMsdCode: TwelveLetterCode
+cifCode: ThreeLetterCode
+varCifCode: ThreeLetterCode
+formula: Line
+formalCharge: Int
+molecularMass: Float
+nonStereoSmiles: String
+stereoSmiles: String
+isParamagnetic: Boolean
+isAromatic: Boolean
*
+boundChemAtom
1
*
+molType: MolType
+ccpCode: Word
+name: Text
+code3Letter: ThreeLetterCode
+msdCode: TwelveLetterCode
+cifCode: ThreeLetterCode
+code1Letter: Word
+commonNames: Text
+stdChemCompCode: Word
+keywords: Line
+merckCode: Word
+sigmaAldrichCode: Word
+beilsteinCode: Word
+casRegCode: Word
+details: Text
+hasStdChirality: Boolean
+isLinearPolymer: Boolean
1
*
1
*
ChemBond
+bondType: BondType = single
+stereochem: BondStereochemistry
1
*
ChemAtom
+chirality: AtomChirality
+nuclGroupType: Word
+elementSymbol: Word
+shortVegaType: Line
+waterExchangeable: Boolean = False
+chemAtoms
2
+chemAtoms
*
AbstractChemAtom
+chemAtoms
*
+name: Word
+subType: Int = 1
More Concepts
• Parent links
– Join all objects in a tree,
rooted in MemopsRoot/Project
• Local keys
–
–
–
–
Uniquely identify an object relative to its siblings
One or more attributes or links
Use serial number if no other candidate
Combined to form global keys
• Derived attributes and links
– Not stored, but calculated when needed
– Behave like normal attributes
ChemElement - Details
ccp.nmr.Nmr.Resonance
memops.Implementation.Project
+serial: Int
+name: Word
+assignNames: Word
+isotopeCode: Word
+details: Text
1
ChemElementStore
+getIsotope()
*
+covalentlyBound
+currentChemElementStore
*
ccp.molecule.ChemComp.ChemAtom
+name: Line
*
+chirality: AtomChirality
+nuclGroupType: Word
+elementSymbol: Word
+shortVegaType: Line
+waterExchangeable: Boolean = False
1
+covalentlyBound
*
+getChemElement()
ChemElement
+symbol: Token
+atomNumber: Int
+atomicRadius: Float
+covalentRadius: Float
+mass: Float
+name: Token
ccp.nmr.Nmr.ShiftReference
+serial: Int
+isotopeCode: Word
+molName: ShiftReferenceMolecule
+atomGroup: Line
+unit: Word = ppm
+value: Float
+referenceType: ShiftRefType
+indirectShiftRatio: Double
ccp.nmr.Nmr.ExpDimRef
1
*
Isotope
+getIsotope()
1
ccp.nmr.NmrConstraint.ChemShiftConstraintList
+isotopeCode: Word
+getIsotope()
1
1
+massNumber: Int
+gyroMagneticRatio: Float
+spin: Word
+mass: Float
+abundance: Float
+receptivity: Float
+magneticMoment: Float
+quadrupoleMoment: Float
*
+serial: Int
+sf: Float
+isotopeCodes: Word
+measurementType: ExpMeasurementType = shift
+isFolded: Boolean = False
+unit: Word
+isSplitting: Boolean = False
+isAxisReversed: Boolean = True
+maxAliasedFreq: Float
+minAliasedFreq: Float
+hasAliasedFreq: Boolean
+variableIncrFraction: FloatRatio
+constantTimePeriod: Float
+nominalRefValue: Float
+baseFrequency: Float
+getIsotopes()
+getHasAliasedFreq()
TopObjects and Implementation
• TopObjects
– Every package has a TopObject
(e.g. ChemComp, NmrProject)
– TopObjects are children of MemopsRoot/Project
– File Implementations have one file per TopObject.
– No links between objects from same package with
different TopObjects
– TopObjects have universal identifiers (GUID)
• Implementation package contains no real
data, only file and database locations
Implementation 1.1
MemopsDataObject
+applicationData: ApplicationData
+locationInfo
LocationInfo
*
+storedPackage: Word = any
MemopsObject
GenericTopObject
+topObject
+backedUp
*
* +stored
1
{ordered}
+backup
1
* +repositories
Repository
+serial: Int
+name: Line
+format: Word = XML
+url: Url
+root
MemopsRoot
+override: Boolean = False
FileTopObject
* +repositories 1
1
FileMemopsRoot
+backup
1
+saveModified()
+saveAll()
AbstractTopObject
+guid: Line
+applicationData: ApplicationData
+dump()
+restore()
Constraints
•
Frozen (unchangeable) attribute
– Change-once to be introduced
•
Cardinality
– 0..1, 1..1, 2..2, n..m, * (0..infinity)
•
Collections
– Unique, unordered = set
– Nonunique, ordered = list
– Unique, ordered = list with uniqueness checking
• Ad-hoc (handcoded) constraints
– DataType (value)
– Attribute and Link (object and value)
– Class (object)
•
Constraints are always enforced.
Handcode
•
In constraints on DataType, Class, or Element
•
In function bodies
– May override an autogenerated function
e.g. a getter for a derived element
– May define a new function, e.g. MemopsRoot.saveAll
•
To be added at the end of constructors,
e.g. to create more objects automatically
•
To be added at the beginning of delete,
e.g. to prevent delete in some situations.
• Handcode is entered separately for each language
Simple data types
«DataType»
Boolean
«DataType»
UrlProtocol
«DataType»
Float
«DataType»
Word
«DataType»
String
«DataType»
Text
«DataType»
Double
«DataType»
SingleLine
«DataType»
Long
«DataType»
Line
«DataType»
Int
«DataType»
NonNegativeInt
«DataType»
PositiveInt
Complex data types (example)
«DataType»
ApplicationData
+application: Line
+keyword: Line
«DataType»
AppDataDouble
«DataType»
AppDataFloat
+value: Double
+value: Float
«DataType»
AppDataBoolean
+value: Boolean
«DataType»
AppDataInt
+value: Int
«DataType»
AppDataLong
«DataType»
AppDataString
+value: Long
+value: String
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
API facilities
• Data access only (get, set, create, delete, …)
– CCPN does not do things with the data –
that is up to you
• Data Encapsulation
– Internal lists etc. not returned outside objects
• Functions only defined where they make sense
– No ‘add’ functions for frozen or 2..2 links
• Functions raise error if they cannot do their job
API examples
Examplkes are java specific. Many (but not
all) would look identical in Python. In
Python we also use keyword arguments,
and allow the standard Python syntax
( value = obj.attr, obj.attr = value).
ChemComp – basis for examples
ChemComp
1
ChemCompVar
*
*
LinkEnd
+linkCode: Word
*
+boundLinkEnd
+boundLinkEnds
1
+boundLinkAtom
LinkAtom
+elementSymbol: Word
+linking: ChemCompLinking
* +descriptor: Line
+isDefaultVar: Boolean = False
+name: Text
+varName: Text
+msdCode: TwelveLetterCode
+varMsdCode: TwelveLetterCode
+cifCode: ThreeLetterCode
+varCifCode: ThreeLetterCode
+formula: Line
+formalCharge: Int
+molecularMass: Float
+nonStereoSmiles: String
+stereoSmiles: String
+isParamagnetic: Boolean
+isAromatic: Boolean
*
+boundChemAtom
1
*
+molType: MolType
+ccpCode: Word
+name: Text
+code3Letter: ThreeLetterCode
+msdCode: TwelveLetterCode
+cifCode: ThreeLetterCode
+code1Letter: Word
+commonNames: Text
+stdChemCompCode: Word
+keywords: Line
+merckCode: Word
+sigmaAldrichCode: Word
+beilsteinCode: Word
+casRegCode: Word
+details: Text
+hasStdChirality: Boolean
+isLinearPolymer: Boolean
1
*
1
*
ChemBond
+bondType: BondType = single
+stereochem: BondStereochemistry
1
*
ChemAtom
+chirality: AtomChirality
+nuclGroupType: Word
+elementSymbol: Word
+shortVegaType: Line
+waterExchangeable: Boolean = False
+chemAtoms
2
+chemAtoms
*
AbstractChemAtom
+chemAtoms
*
+name: Word
+subType: Int = 1
Get
• x = myChemComp.getMerckCode()
returns value
• x = myChemCompVar.getChemAtoms()
returns list or set of values
• Function always present
Set
• myChemComp.setMerckCode(x)
sets value – x may be null if constraints permit
• myChemCompVar.setChemAtoms(atList)
– accepts any collection values
– removes old values and sets new ones
– only function that can reorder ordered elements
• Function not present for frozen elements,
or for parent or child links
• May be present for derived elements
• First checks cardinality and handcoded constraints
(unless called from a constructor)
Add, remove
• myChemCompVar.addChemAtom(atom)
myChemCompVar.removeChemAtom(atom)
• Function not present for frozen elements,
parent elements, child elements,
or where cardinality is n..n.
• May be present for derived elements
• First checks cardinality and handcoded
constraints (unless called from a constructor)
Sorted and current
•
myList = myChemComp.sortedChemAtoms()
myList = myChemCompVar.sortedChemAtoms()
– For child links sorts on local key (here ‘name’, ‘subtype’)
– For other link sorts on full key (here ‘molType’, ‘ccpCode’, ‘name’,
‘subtype’)
• Function present for unordered multiple links
• myChemComp = myProject.getCurrentChemComp()
• Only between MemopsRoot/Project and TopObjects.
• Remembered between sessions
findFirst and findAll
•
myBond = myChemComp.findFirstChemAtom(constraintMap)
•
myAtom = myChemComp.findFirstChemAtom(“name”, “HA”,
“subType”, 1)
•
myAtom = myChemComp.findFirstChemAtom()
•
atList = myChemComp.findAllChemAtoms(“name”, “HA”)
– Selects or filters based on ‘self.keyword == value’
– findFirst mainly used where there is at most one element that fits,
or where you want a random element.
• Function present for all multiple links, also if derived
Delete
• myObj.delete()
– sets myObj.isDeleted=True
– removes all known links from undeleted
objects to myObj
– Recursively deletes any object that:
• has a frozen or add-once link to myObj
(this includes all children)
• has a mandatory (n..n) link to myObj
• has an n..m link to myObj if there are fewer than n
objetcs left in the link
Object Creation
• newLinkAtom = new ChemAtom(myChemComp, “HA”, 2)
• newLinkAtom = myChemComp.newChemAtom(“HA”, 1)
• newAtom = myChemComp.newChemAtom(attrLinkMap)
•
Suspends most validity checking,
but calls myObj.checkValid() afterwards.
Validity Checking
• myObj.checkValid()
– Checks that object and their attributes and links satisfy
cardinality and handcoded constraints
• myObj.checkAllValid()
– recursively calls checkValid for myObj and all child objects.
• If called as ‘checkValid(True)’
either function also checks DataType constraints,
and that two-way links are self-consistent.
– ‘complete=True’ is slow!
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
Resources
• University of Cambridge (CCPN grant)
• Wayne Boucher
• Code generation, installation, C routines
• Rasmus Fogh
• Code generation, Data Model
• Tim Stevens
• CcpNmr Analysis and NEXUS, user interface
• Position unfilled
• Interfacing NMR applications
• EBI – MSD group
• Wim Vranken
• NMR Databases, reference information, CcpNmr FormatConverter
• Anne Pajon (PIMS)
• Java/SQL implementation, LIMS model, PIMS
Ongoing code generation upgrade
 New capabilities





Result generally streamlined
Machinery easier to expand and maintain
New collection types (sets)
Complex datatype objects
Cleaner, more DB-friendly model
 Changes
 New MetaModel
 All generation scripts (to be) reorganised
 Model change for core (Implementation)
package
 NB Old application code must change!
CCPN / U Cambridge objectives
 Short term





Further develop CcpNmr Analysis and NEXUS
Promote CCPN software and collaboration
Further integrate third-party NMR software
Upgrade all implementations to newest version
Support existing collaborations
 Medium term
 Expand data model to structural/systems biology
 Sample description, molecular dynamics, …
 Additional collaborations
 Add new implementations
 Long term
 Help create LIMS system that includes structural NMR
 Add Client/server code generation
Major Collaborations
 EXTEND-NMR, EUNMR
 NMR software integration
 BIOXDM
 Beamline crystallography online software
 Model for Experimental crystallography
 EUROCarbDB
 Carbohydrate NMR
 PIMS
 LIMS system
 Biochemistry/Biology laboratory data model
 has suspended collaboration pending review
Languages and Formats
Almost Ready
Awaiting upgrade
New Implementation
requested
Format
Python
XML
SQL
Analysis,
FormatConverter
Language
Java
Extend-NMR
Bruker
TopSpin,
NMRVIEW
MSD NMR
database,
BIOXDM ?
PIMS,
BIOXDM ?
EuroCarbDB?
C
Processing
Extend-NMR,
EU-NMR,
AUTOPSY,
(Varian)
(CYANA)
Perl
(Bioinformatics)
(Bioinformatics)
Python and C APIs

Python/XML




Available in newest stable release
API upgrade complete, partially tested
XML I/O upgrade in progress
C/XML


Full functionality available in newest stable release
Wrapper around Python API code



calls C libraries from the Python distribution
Native implementation planned – should be faster.
Python/database

Under discussion
Java APIs

Java/XML


PIMS/Java/SQL



Available in newest stable release
Currently working and in use in PIMS
Older, dead-end branch. Upgrade or lose support
Java/SQL

Requires completion of new-machinery upgrade.
1.
2.
3.
4.
New Model. Instantaneous
New DB Schema and Hibernate mapping. <1 man-month
New Java/XML API. Further 2 man months
New Java/SQL API. Further 2 man-months
Current Java/SQL/PIMS Implementation




Generation not integrated with main machinery.
Model structure two versions behind stable release
Some essential functionality in PIMS-specific code
LIMS model only. Hand coding missing for other
model parts
 Missing:
 ‘sorted’, ‘checkValid’, ‘newChildClass’ factory functions
Attribute, link, and class constraints.
Constructor and destructor handcode.
Support for some cardinalities (e.g. 2..2)
 Works differently:
 ‘findFirst’, ‘findAll’, constructors
object composite key. Object print.
Constraint evaluation policy.
Handcode handling
Size statistics
 Data Model
 38 packages
 467 classes, datatypes and dataobjtypes
 XML description 14 500 lines
 Python/XML API
 API code 530 000 lines (17 000 000 chars)
 XML I/O mappings 46 000 lines (1 100 000 chars)
 Handcode 38 000 chars (0.2%)
 Generation machinery
 31 000 lines of Python
■ CCPN aims
■ Data standards
■ Code Generation and libraries
■ Data Model structure
■ API details
■ Status, resources and plans
■ Credits
CCPN people
• Cambridge (Biochemistry)
–
–
–
–
–
–
–
Ernest Laue
Wayne Boucher
Rasmus Fogh
Tim Stevens
Dan O’Donovan
Wolfgang Rieping
Alan da Silva
• EBI (MSD), Hinxton
–
–
–
–
Kim Henrick
John Ionides
Wim Vranken
Anne Pajon
• Plus external collaborators
Funding
• BBSRC (UK research council)
• Industry
– AstraZeneca, Dupont Pharma (now BMS), Genentech,
GlaxoSmithKline
• European Community
– EXTEND-NMR, EU-NMR, NMR-Life, NMRQUAL, and
TEMBLOR contracts
Collaborations
• Institututions
– Carnegie Mellon University, Institut Pasteur,
University of Gothenburg, University of Nijmegen,
University of Utrecht, University of Regensburg, FMP,
BRI, EBI-MSD, BMRB, Bruker, Global Phasing, IGBMC,
LEBS, NKI and RCSB
• Projects
–
–
–
–
EXTEND-NMR (NMR software)
PIMS (Biochemistry LIMS)
BIOXDM (Beamline crystallography)
EUROCarbDB (Carbohydrate data)
END