Refine
Year of publication
- 2013 (3) (remove)
Document Type
- Article (2)
- Monograph/Edited Volume (1)
Is part of the Bibliography
- yes (3)
Keywords
- bacterial O-antigen (2)
- carbohydrate interaction (2)
- structural thermodynamics (2)
- tailspike protein (2)
- Anfragesprache (1)
- Datenbank (1)
- Geschäftsanwendungen (1)
- Hauptspeicherdatenbank (1)
- Nebenläufigkeit (1)
- Programmierkonzepte (1)
Bacteriophage P22 recognizes O-antigen polysaccharides of Salmonella enterica subsp. enterica (S.) with its tailspike protein (TSP). In the serovars S. Typhimurium, S. Enteritidis, and S. Paratyphi A, the tetrasaccharide repeat units of the respective O-antigens consist of an identical main chain trisaccharide but different 3,6-dideoxyhexose substituents. Here, the epimers abequose, tyvelose and paratose determine the specific serotype. P22 TSP recognizes O-antigen octasaccharides in an extended binding site with a single 3,6-dideoxyhexose binding pocket. We have isolated S. Paratyphi A octasaccharides which were not available previously and determined the crystal structure of their complex with P22 TSP. We discuss our data together with crystal structures of complexes with S. Typhimurium and S. Enteritidis octasaccharides determined earlier. Isothermal titration calorimetry showed that S. Paratyphi A octasaccharide binds P22 TSP less tightly, with a difference in binding free energy of similar to 7 kJ mol(-1) at 20 degrees C compared with S. Typhimurium and S. Enteritidis octasaccharides. Individual protein-carbohydrate contacts were probed by amino acid replacements showing that the dideoxyhexose pocket contributes to binding of all three serotypes. However, S. Paratyphi A octasaccharides bind in a conformation with an energetically unfavorable phi/epsilon glycosidic bond angle combination. In contrast, octasaccharides from the other serotypes bind as solution-like conformers. Two water molecules are conserved in all P22 TSP complexes with octasaccharides of different serotypes. They line the dideoxyhexose binding pocket and force the S. Paratyphi A octasaccharides to bind as nonsolution conformers. This emphasizes the role of solvent as part of carbohydrate binding sites.
Bacteriophage HK620 recognizes and cleaves the O-antigen polysaccharide of Escherichia coli serogroup O18A1 with its tailspike protein (TSP). HK620TSP binds hexasaccharide fragments with low affinity, but single amino acid exchanges generated a set of high-affinity mutants with submicromolar dissociation constants. Isothermal titration calorimetry showed that only small amounts of heat were released upon complex formation via a large number of direct and solvent-mediated hydrogen bonds between carbohydrate and protein. At room temperature, association was both enthalpy- and entropy-driven emphasizing major solvent rearrangements upon complex formation. Crystal structure analysis showed identical protein and sugar conformers in the TSP complexes regardless of their hexasaccharide affinity. Only in one case, a TSP mutant bound a different hexasaccharide conformer. The extended sugar binding site could be dissected in two regions: first, a hydrophobic pocket at the reducing end with minor affinity contributions. Access to this site could be blocked by a single aspartate to asparagine exchange without major loss in hexasaccharide affinity. Second, a region where the specific exchange of glutamate for glutamine created a site for an additional water molecule. Side-chain rearrangements upon sugar binding led to desolvation and additional hydrogen bonding which define this region of the binding site as the high-affinity scaffold.
Die Komplexität heutiger Geschäftsabläufe und die Menge der zu verwaltenden Daten stellen hohe Anforderungen an die Entwicklung und Wartung von Geschäftsanwendungen. Ihr Umfang entsteht unter anderem aus der Vielzahl von Modellentitäten und zugehörigen Nutzeroberflächen zur Bearbeitung und Analyse der Daten. Dieser Bericht präsentiert neuartige Konzepte und deren Umsetzung zur Vereinfachung der Entwicklung solcher umfangreichen Geschäftsanwendungen. Erstens: Wir schlagen vor, die Datenbank und die Laufzeitumgebung einer dynamischen objektorientierten Programmiersprache zu vereinen. Hierzu organisieren wir die Speicherstruktur von Objekten auf die Weise einer spaltenorientierten Hauptspeicherdatenbank und integrieren darauf aufbauend Transaktionen sowie eine deklarative Anfragesprache nahtlos in dieselbe Laufzeitumgebung. Somit können transaktionale und analytische Anfragen in derselben objektorientierten Hochsprache implementiert werden, und dennoch nah an den Daten ausgeführt werden. Zweitens: Wir beschreiben Programmiersprachkonstrukte, welche es erlauben, Nutzeroberflächen sowie Nutzerinteraktionen generisch und unabhängig von konkreten Modellentitäten zu beschreiben. Um diese abstrakte Beschreibung nutzen zu können, reichert man die Domänenmodelle um vormals implizite Informationen an. Neue Modelle müssen nur um einige Informationen erweitert werden um bereits vorhandene Nutzeroberflächen und -interaktionen auch für sie verwenden zu können. Anpassungen, die nur für ein Modell gelten sollen, können unabhängig vom Standardverhalten, inkrementell, definiert werden. Drittens: Wir ermöglichen mit einem weiteren Programmiersprachkonstrukt die zusammenhängende Beschreibung von Abläufen der Anwendung, wie z.B. Bestellprozesse. Unser Programmierkonzept kapselt Nutzerinteraktionen in synchrone Funktionsaufrufe und macht somit Prozesse als zusammenhängende Folge von Berechnungen und Interaktionen darstellbar. Viertens: Wir demonstrieren ein Konzept, wie Endnutzer komplexe analytische Anfragen intuitiver formulieren können. Es basiert auf der Idee, dass Endnutzer Anfragen als Konfiguration eines Diagramms sehen. Entsprechend beschreibt ein Nutzer eine Anfrage, indem er beschreibt, was sein Diagramm darstellen soll. Nach diesem Konzept beschriebene Diagramme enthalten ausreichend Informationen, um daraus eine Anfrage generieren zu können. Hinsichtlich der Ausführungsdauer sind die generierten Anfragen äquivalent zu Anfragen, die mit konventionellen Anfragesprachen formuliert sind. Das Anfragemodell setzen wir in einem Prototypen um, der auf den zuvor eingeführten Konzepten aufsetzt.