The PDB and experimental data
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Westbrook, John
This presentation covers: current PDB audience and growth; the range of primary experimental metadata in the PDB; challenges for data acquisition and deposition across the PDB view of the structural biology data pipeline; how we are addressing these challenges.
 Experimental data. Thank you very much, John. So, Brian, can you see the screen? So, thanks to John and Brian for making the arrangement for PDB to participate in the workshop and making all the remote communication arrangements. The streaming of the meeting over YouTube is working very well. It's very clear. So, I'd like to talk on a topic that's a little bit different prior to making the arrangement for PDB to participate in the workshop and making all the remote communication. So, I hope you're not hearing an echo. I've cut down my microphone. I'm hearing a very significant... I'm cutting off my stream. So, at the moment you're coming across clearly on the audio. Okay, good. That's fine. So, I'm going to focus a little bit about talking about the experimental data collected by the PDB, the challenges that we are confronting collecting data from the user community and through our deposition interface across the whole PDB structural biology pipeline, at least the view of that that the PDB sees, and how we're addressing some of the challenges that are part of that. So, to begin with, I think everybody is familiar with the PDB. The molecule on the right is what most of our end user community is interested in. And the majority of our use now has shifted from a depositor-centric user community to a much broader community of biologists and users in related disciplines. So, as we're discussing metadata and interoperation among groups using metadata, I think it's useful to point out that the PDB itself is a collaborative organization among the partner sites that collect depositions to the PDB from the group in the U.S., ERCSB, PDBJ and Osaka, and PDB in Kingston, and our NMR partner in Wisconsin. One of the key aspects of the collaboration as highlighted in red here is the agreement to use a common metadata representation. And that was the process of arriving at that agreement was something that took more than a few years. But it's become the foundation for our interaction with respect to how we process and manage the archive. So, the archive continues to grow here. We're looking at the number of depositions reflecting the product of much of the work of members of the audience. And the use of the archive is quite impressive worldwide, the number of downloads per year is of the order of 500 million. So, the complexity of the archive continues to grow here, represented in terms of molecular complexity, in terms of the number of small molecules and medium sized molecules within a PDB entry. Perhaps the next time this workshop is convened, the complexity graph is going to reflect sort of the emerging complexity that comes from entries which will be based on primary experimental data from more than just a single method. So, what I'd like to do is to talk a little bit about what primary data looks like from the PDB perspective, while this workshop has been or is focused very specifically on issues of raw image data. I think it's important to keep in mind, particularly from the protein perspective, that the sample is a very important component of the primary data. And keeping track of the sample and the metadata required to do that is essential if you want to be able to have the opportunity to take advantage of the products of the archiving of more primary image data. The kinds of information that we try to acquire at deposition time include the details of composition, as accurate as possible, chemical and molecular descriptions of all the components, source organism production details, and experimentally determined biological role if possible, and then sample and specimen issues such as crystallization conditions and any post treatments. So, we captured data collection information at a very coarse level of detail compared to the level of detail that's been discussed so far in this workshop, largely in terms of instrumentation, sample handling, and data collection protocols at a very high level. And then I think everyone would agree that there are a few steps that are sort of left out of PDB's pipeline, which is largely the subject of this workshop, which is the raw image data that is contributed to the PDB after significant amount of processing. So, our view of the primary data, as I'm sure all of you know, is largely in terms of the summary statistics from data processing operations, the software steps, and the software tools that were used in that, and the process data itself. Currently in the archive, we have about 98% of the X-ray entries have structure factor amplitude data. This information has been mandatory at deposition since 2008. Within the entries that contain where we have structure factor data, it's been traditional to provide the final reflection data as the first data set in potentially a multi-data set. SIF packaging, about 10,000 additional data sets are available, which variably contain either derivative or multi-wavelength data sets and immediate phasing data and map coefficients. And for a small number of cases, currently, unmerged intensities. So, if we shift a little bit to data acquisition from the perspective of the PDB, the model on the left, which perhaps is the largest volume of the data, is actually the most straightforward aspect of our data collection pipeline. The sample information that I've been discussing is actually quite a bit more challenging. Our pipeline, as I said, is based on, for data collection and deposition, is based on the agreed metadata framework, which is entirely instrumented across the full pipeline in MM SIF. And as Herb was discussing in his talk, much of the work of packaging information for the pipeline is done via data harvesting operations. And this is particularly the case for anything having to do with data collection. We have, in the last year and a half, been the benefit of a significant amount of work on behalf of the major protein refinement packages in delivering native MM SIF data files coming out of refinement to the deposition system. But that work doesn't include any information related to, or currently related to, predecessor steps in the pipeline. So sample information and information related to data collection is largely the target of data harvesting operations. So we've been working at this harvesting tooling for some time. We provide websites and software tools, some of which are already embedded in large packages, to do log file and output file harvesting. This is a very pragmatic approach, which we've had to take because of the lack of compliance with metadata. I don't think this is a particularly good future direction to adopt. It's a very high maintenance problem. So we do similar things with process data. Most of this data comes to us in the form of binary packaged files such as MTZ files. And that's all converted. Data is extracted from those formats and put into SIF packaging for deposition. So one of the biggest challenges that we have with respect to the more primary data is the data that we can't harvest ends up having to be manually input in the form of, through a web interface. And this is certainly most true for data collection and sample related information. So that problem is the fact that we don't have a reliable electronic vehicle for packaging metadata associated with the sample is a continuing problem for automating the whole deposition pipeline. We've made some progress in chemical assignment. The similar issues exist there being able to accurately define the chemical descriptions of all the sample components is essential and to be able to accurately represent the experiment and provide for reuse. We provide metadata to define all of the chemical components within the PDB archive and we align incoming data according to that data dictionary. This dictionary is embedded in most of the refinement software packages. So progress is being made in standardizing this, but there are still a ways to go to encode all of the chemical information in a purely electronic form. So just as a brief aside, we collect all of this data and it does in fact percolate up through the pipeline, particularly we're trying to provide more diagnostics and more accessible diagnostics of map model fit and electron density. This is an example from a PDB validation report which all depositors see and go to many journal reviewers. The red dots here indicate fitting issues along the sequence. Similarly, we provide diagnostics on ligands, these are tools that are part of our annotation pipeline. So we're trying to move the data up the pipeline and make it available to the end users as much as possible. So now I'd like to talk a little bit about what we're trying to do to improve the pipeline from the perspective of data organization and metadata. As I mentioned, we benefited greatly from the efforts of a WWPDB working group on deposition standards and representation. This group is currently chaired by Paul Adams and in the last few years has made some very significant advancements in terms of standardizing data for deposition. The group is currently working on delivering standards recommendations for a more robust description of chemical restraints as well as the reorganization of our packaging and delivery of processed, structured factor data and intensities. That will include largely a reorganization of how that data is identified and the contents of each data section that's delivered for an entry so that it will be clear, clear error through improved metadata precisely what each data section contains, the role of that data section and then how it's related to potentially other data sections that have been contributed or to the sample or crystal or to the refine model. And as I said, that will include recommendations for unmerged intensities and map coefficients. I think Tom Chalillegar will be talking more about some of these ideas in a subsequent talk as well as a comprehensive representation of chemical restraints that were used in the refinement. So I said there was a bit of hand waving with respect to some of the experimental details and the way that we're trying to address that is allowing depositors to identify related experimental data. So this is just a quick view of the manner in which we're doing that now. The bottom panel here shows a snapshot from the current deposition, our current deposition interface, and this is largely the ability to represent a doi for a particular data set and doi for the related metadata that might be needed to describe that associated with text descriptions of both of those data objects. And as many of those as need be can be entered. So this is our current strategy and this could be used or actually is being used now to link data to a sample of archives here. As Vlad described his new work on the protein diffraction archive, TARDIS has been around for quite a while and then in other areas we provide linkages for NMR data, SAS data, and primary data and processed volume data for electron microscopy. So let me end with a view of the direction that we are trying to move in currently. And this is reflected in a recent paper that was the result describing a working group workshop on hybrid and integrated methods. And the idea is that one path forward for dealing with a very diverse set of data resources is to think of these data resources as loosely coupled but having the ability to exchange data at whatever level of detail is appropriate between resources based on shared metadata standards. And in doing that it gives each resource the opportunity to define its own standards. It doesn't impose complicated control issues between resources. It only requires that people identify the shared bits that they need to exchange and that is the direction that we are currently working in right now and based on our experience we think that this is a useful model for. So finally I'd like to thank the other members of the WWPDB which we collaborate with and the various organizations within NSF and NIH that fund the PDB in the US. So thanks very much. My question is important. I get a question. The PDB is still going after this topic and you talk about data. You've got a question. I want to jump to a very clear presentation and take the time to join us. In the end of the last week I asked a managerial question. What will success look like? So in the context of how you see the PDB what is the final vision for where you're trying to strive to get to? So very practically for current conventional methods to be able to have a robust enough data representation that is populated by the software packages that are our primary data generators that the use of sort of a web form based interface is no longer necessary so that you have basically a simple one button kind of deposition system. This is increasingly with larger and more complicated structures that have complicated, require complicated descriptions of chemistry. The lack of having that information accurately encoded electronically on the front end puts a huge burden on the depositor to deliver that data. More broadly we're looking at having experiments with data sets coming from a variety of different experimental techniques and the ability to represent the structural restraints that are required to assess the quality of those structures and to link those restraints back to the primary data sets in this federated model is sort of the next generation of what we believe will be required to support structural biology. If I may have a supplementary to that then the 500 million downloads per year I think clearly tells us that not specialists predominantly are using the information. On that part of the whole point of the issue I might call precision but the coordinates, the occupancy of the factors is a crystallographic analysis. We're not going to be known to predominant practical uses of the information. So it's obvious from my own personal ethics with colleagues mainly to try and do something about the coordinate precision and provide information on that. So I would hope for some portion of the vision where we aim for ultimate is to have a better clarity of precision that we think there is better coordinates and the effectiveness of the data. Okay so I will speak. The WWPDB is focused on the data input pipeline and delivering data into a repository with a common representation. On the delivery side I think it's quite clear that the user community is going to want to see the best version of the data. So we're going to be able to see the best version of a particular biological model, structural biology model and being able to deliver data with assessment, with quality assessment that's understandable to a non-specialist community is something that we are. We're all trying to achieve that's embodied in the presentation, the simplified presentation of validation information that is being provided currently and it's anticipated that that will evolve significantly in coming years. And the ability to better support multiple interpretations of data sets and all of those sorts of things are certainly challenges that PDB will be addressing. Thank you. Thank you very much again John for an excellent and thought provoked presentation. Thank you for taking the trouble to be with us across the Atlantic and I look forward to meeting up again in person before very much longer. Thank you.
 Experimental data. Thank you very much, John.  So, Brian, can you see the screen?  So, thanks to John and Brian for making the arrangement for PDB to participate in the workshop  and making all the remote communication arrangements.  The streaming of the meeting over YouTube is working very well. It's very clear.  So, I'd like to talk on a topic that's a little bit different prior to making the arrangement for PDB to participate in the workshop and making all the remote communication.  So, I hope you're not hearing an echo. I've cut down my microphone.  I'm hearing a very significant...  I'm cutting off my stream.  So, at the moment you're coming across clearly on the audio.  Okay, good.  That's fine.  So, I'm going to focus a little bit about talking about the experimental data collected by the PDB,  the challenges that we are confronting collecting data from the user community and through our deposition interface  across the whole PDB structural biology pipeline, at least the view of that that the PDB sees,  and how we're addressing some of the challenges that are part of that.  So, to begin with, I think everybody is familiar with the PDB.  The molecule on the right is what most of our end user community is interested in.  And the majority of our use now has shifted from a depositor-centric user community to a much broader community of biologists  and users in related disciplines.  So, as we're discussing metadata and interoperation among groups using metadata,  I think it's useful to point out that the PDB itself is a collaborative organization among the partner sites  that collect depositions to the PDB from the group in the U.S., ERCSB, PDBJ and Osaka,  and PDB in Kingston, and our NMR partner in Wisconsin.  One of the key aspects of the collaboration as highlighted in red here is the agreement to use  a common metadata representation.  And that was the process of arriving at that agreement was something that took more than a few years.  But it's become the foundation for our interaction with respect to how we process and manage the archive.  So, the archive continues to grow here.  We're looking at the number of depositions reflecting the product of much of the work of members of the audience.  And the use of the archive is quite impressive worldwide, the number of downloads per year is of the order of 500 million.  So, the complexity of the archive continues to grow here, represented in terms of molecular complexity,  in terms of the number of small molecules and medium sized molecules within a PDB entry.  Perhaps the next time this workshop is convened, the complexity graph is going to reflect  sort of the emerging complexity that comes from entries which will be based on primary experimental data from more than just a single method.  So, what I'd like to do is to talk a little bit about what primary data looks like from the PDB perspective,  while this workshop has been or is focused very specifically on issues of raw image data.  I think it's important to keep in mind, particularly from the protein perspective,  that the sample is a very important component of the primary data.  And keeping track of the sample and the metadata required to do that is essential if you want to be able to have the opportunity to take advantage of the products of the archiving of more primary image data.  The kinds of information that we try to acquire at deposition time include the details of composition,  as accurate as possible, chemical and molecular descriptions of all the components, source organism production details,  and experimentally determined biological role if possible, and then sample and specimen issues such as crystallization conditions and any post treatments.  So, we captured data collection information at a very coarse level of detail compared to the level of detail that's been discussed so far in this workshop, largely in terms of instrumentation, sample handling,  and data collection protocols at a very high level.  And then I think everyone would agree that there are a few steps that are sort of left out of PDB's pipeline, which is largely the subject of this workshop,  which is the raw image data that is contributed to the PDB after significant amount of processing.  So, our view of the primary data, as I'm sure all of you know, is largely in terms of the summary statistics from data processing operations,  the software steps, and the software tools that were used in that, and the process data itself.  Currently in the archive, we have about 98% of the X-ray entries have structure factor amplitude data.  This information has been mandatory at deposition since 2008.  Within the entries that contain where we have structure factor data,  it's been traditional to provide the final reflection data as the first data set in potentially a multi-data set.  SIF packaging, about 10,000 additional data sets are available, which variably contain either derivative or multi-wavelength data sets and immediate phasing data and map coefficients.  And for a small number of cases, currently, unmerged intensities.  So, if we shift a little bit to data acquisition from the perspective of the PDB,  the model on the left, which perhaps is the largest volume of the data, is actually the most straightforward aspect of our data collection pipeline.  The sample information that I've been discussing is actually quite a bit more challenging.  Our pipeline, as I said, is based on, for data collection and deposition, is based on the agreed metadata framework,  which is entirely instrumented across the full pipeline in MM SIF.  And as Herb was discussing in his talk, much of the work of packaging information for the pipeline is done via data harvesting operations.  And this is particularly the case for anything having to do with data collection.  We have, in the last year and a half, been the benefit of a significant amount of work on behalf of the major protein refinement packages  in delivering native MM SIF data files coming out of refinement to the deposition system.  But that work doesn't include any information related to, or currently related to, predecessor steps in the pipeline.  So sample information and information related to data collection is largely the target of data harvesting operations.  So we've been working at this harvesting tooling for some time.  We provide websites and software tools, some of which are already embedded in large packages, to do log file and output file harvesting.  This is a very pragmatic approach, which we've had to take because of the lack of compliance with metadata.  I don't think this is a particularly good future direction to adopt. It's a very high maintenance problem.  So we do similar things with process data.  Most of this data comes to us in the form of binary packaged files such as MTZ files.  And that's all converted. Data is extracted from those formats and put into SIF packaging for deposition.  So one of the biggest challenges that we have with respect to the more primary data is the data that we can't harvest  ends up having to be manually input in the form of, through a web interface.  And this is certainly most true for data collection and sample related information.  So that problem is the fact that we don't have a reliable electronic vehicle for packaging metadata associated with the sample  is a continuing problem for automating the whole deposition pipeline.  We've made some progress in chemical assignment. The similar issues exist there being able to accurately define the chemical descriptions  of all the sample components is essential and to be able to accurately represent the experiment and provide for reuse.  We provide metadata to define all of the chemical components within the PDB archive and we align incoming data according to that data dictionary.  This dictionary is embedded in most of the refinement software packages.  So progress is being made in standardizing this, but there are still a ways to go to encode all of the chemical information in a purely electronic form.  So just as a brief aside, we collect all of this data and it does in fact percolate up through the pipeline, particularly we're trying to provide more diagnostics  and more accessible diagnostics of map model fit and electron density.  This is an example from a PDB validation report which all depositors see and go to many journal reviewers.  The red dots here indicate fitting issues along the sequence.  Similarly, we provide diagnostics on ligands, these are tools that are part of our annotation pipeline.  So we're trying to move the data up the pipeline and make it available to the end users as much as possible.  So now I'd like to talk a little bit about what we're trying to do to improve the pipeline from the perspective of data organization and metadata.  As I mentioned, we benefited greatly from the efforts of a WWPDB working group on deposition standards and representation.  This group is currently chaired by Paul Adams and in the last few years has made some very significant advancements in terms of standardizing data for deposition.  The group is currently working on delivering standards recommendations for a more robust description of chemical restraints as well as the reorganization of our packaging and delivery of processed,  structured factor data and intensities. That will include largely a reorganization of how that data is identified and the contents of each data section that's delivered for an entry so that it will be clear,  clear error through improved metadata precisely what each data section contains, the role of that data section and then how it's related to potentially other data sections that have been contributed or to the sample or crystal or to the refine model.  And as I said, that will include recommendations for unmerged intensities and map coefficients. I think Tom Chalillegar will be talking more about some of these ideas in a subsequent talk as well as a comprehensive representation of chemical restraints that were used in the refinement.  So I said there was a bit of hand waving with respect to some of the experimental details and the way that we're trying to address that is allowing depositors to identify related experimental data.  So this is just a quick view of the manner in which we're doing that now. The bottom panel here shows a snapshot from the current deposition, our current deposition interface, and this is largely the ability to represent a doi for a particular data set and doi for the related metadata that might be needed to describe that  associated with text descriptions of both of those data objects. And as many of those as need be can be entered.  So this is our current strategy and this could be used or actually is being used now to link data to a sample of archives here.  As Vlad described his new work on the protein diffraction archive, TARDIS has been around for quite a while and then in other areas we provide linkages for NMR data, SAS data, and primary data and processed volume data for electron microscopy.  So let me end with a view of the direction that we are trying to move in currently.  And this is reflected in a recent paper that was the result describing a working group workshop on hybrid and integrated methods. And the idea is that one path forward for dealing with a very diverse set of data resources  is to think of these data resources as loosely coupled but having the ability to exchange data at whatever level of detail is appropriate between resources based on shared metadata standards.  And in doing that it gives each resource the opportunity to define its own standards. It doesn't impose complicated control issues between resources.  It only requires that people identify the shared bits that they need to exchange and that is the direction that we are currently working in right now and based on our experience we think that this is a useful model for.  So finally I'd like to thank the other members of the WWPDB which we collaborate with and the various organizations within NSF and NIH that fund the PDB in the US. So thanks very much.  My question is important.  I get a question. The PDB is still going after this topic and you talk about data.  You've got a question.  I want to jump to a very clear presentation and take the time to join us.  In the end of the last week I asked a managerial question. What will success look like?  So in the context of how you see the PDB what is the final vision for where you're trying to strive to get to?  So very practically for current conventional methods to be able to have a robust enough data representation that is populated by the software packages that are our primary data generators that the use of sort of a web form based interface is no longer  necessary so that you have basically a simple one button kind of deposition system.  This is increasingly with larger and more complicated structures that have complicated, require complicated descriptions of chemistry.  The lack of having that information accurately encoded electronically on the front end puts a huge burden on the depositor to deliver that data.  More broadly we're looking at having experiments with data sets coming from a variety of different experimental techniques and the ability to represent the structural restraints that are required to assess the quality of those structures  and to link those restraints back to the primary data sets in this federated model is sort of the next generation of what we believe will be required to support structural biology.  If I may have a supplementary to that then the 500 million downloads per year I think clearly tells us that not specialists predominantly are using the information.  On that part of the whole point of the issue I might call precision but the coordinates, the occupancy of the factors is a crystallographic analysis.  We're not going to be known to predominant practical uses of the information. So it's obvious from my own personal ethics with colleagues mainly to try and do something about the coordinate precision and provide information on that.  So I would hope for some portion of the vision where we aim for ultimate is to have a better clarity of precision that we think there is better coordinates and the effectiveness of the data.  Okay so I will speak.  The WWPDB is focused on the data input pipeline and delivering data into a repository with a common representation. On the delivery side I think it's quite clear that the user community is going to want to see the best version of the data.  So we're going to be able to see the best version of a particular biological model, structural biology model and being able to deliver data with assessment, with quality assessment that's understandable to a non-specialist community is something that we are.  We're all trying to achieve that's embodied in the presentation, the simplified presentation of validation information that is being provided currently and it's anticipated that that will evolve significantly in coming years.  And the ability to better support multiple interpretations of data sets and all of those sorts of things are certainly challenges that PDB will be addressing.  Thank you.  Thank you very much again John for an excellent and thought provoked presentation. Thank you for taking the trouble to be with us across the Atlantic and I look forward to meeting up again in person before very much longer.  Thank you.
ThePDBandexperimentaldata_0_167.png ThePDBandexperimentaldata_168_863.png ThePDBandexperimentaldata_864_2003.png ThePDBandexperimentaldata_2004_2051.png ThePDBandexperimentaldata_2052_2111.png ThePDBandexperimentaldata_2112_2207.png ThePDBandexperimentaldata_2208_2303.png ThePDBandexperimentaldata_2304_2375.png ThePDBandexperimentaldata_2376_2495.png ThePDBandexperimentaldata_2496_2603.png ThePDBandexperimentaldata_2604_3611.png ThePDBandexperimentaldata_3612_4631.png ThePDBandexperimentaldata_4632_6599.png ThePDBandexperimentaldata_6600_7259.png ThePDBandexperimentaldata_7260_8411.png ThePDBandexperimentaldata_8412_9131.png ThePDBandexperimentaldata_9132_10607.png ThePDBandexperimentaldata_10608_11351.png ThePDBandexperimentaldata_11352_11891.png ThePDBandexperimentaldata_11892_12587.png ThePDBandexperimentaldata_12588_14183.png ThePDBandexperimentaldata_14184_15035.png ThePDBandexperimentaldata_15036_15599.png ThePDBandexperimentaldata_15600_17435.png ThePDBandexperimentaldata_17436_18419.png ThePDBandexperimentaldata_18420_18959.png ThePDBandexperimentaldata_18960_20135.png ThePDBandexperimentaldata_20136_20663.png ThePDBandexperimentaldata_20664_21455.png ThePDBandexperimentaldata_21456_21899.png ThePDBandexperimentaldata_21900_22691.png ThePDBandexperimentaldata_22692_23147.png ThePDBandexperimentaldata_23148_23579.png ThePDBandexperimentaldata_23580_24827.png ThePDBandexperimentaldata_24828_26915.png ThePDBandexperimentaldata_26916_26963.png ThePDBandexperimentaldata_26964_27131.png ThePDBandexperimentaldata_27132_28511.png ThePDBandexperimentaldata_28512_28763.png ThePDBandexperimentaldata_28764_29039.png ThePDBandexperimentaldata_29040_29459.png ThePDBandexperimentaldata_29460_32087.png ThePDBandexperimentaldata_32088_42839.png ThePDBandexperimentaldata_42840_42904.png