Aflatoxin B1-DNA adducts modify the effects of post-operative adjuvant transarterial chemoembolization improving hepatocellular carcinoma prognosis

Aim: DNA damage involves in the carcinogenesis of some cancer and may act as a target for therapeutic intervention of cancers. However, it is unclear whether aflatoxin B1 (AFB1)-DNA adducts (ADAs), an important kind of DNA damage caused by AFB1, affect the efficiency of post-operative adjuvant transarterial chemoembolization (po-TACE) treatment improving hepatocellular carcinoma (HCC) survival. Methods: A hospital-based retrospective study, including 318 patients with Barcelona Clinic Liver Cancer (BCLC)-C stage HCC from high AFB1 exposure areas, to investigate the potential effects of ADAs in the tissues with HCC on po-TACE treatment. The amount of ADAs in the cancerous tissues was tested by competitive enzyme-linked immunosorbent assay (c-ELISA). Results: Among these patients with HCC, the average amount of ADAs was 3.00 µmol/mol ± 1.51 µmol/mol DNA in their tissues with cancer. For these patients, increasing amount of ADAs was significantly associated with poorer overall survival (OS) and tumor reoccurrence-free survival (RFS), with corresponding death risk (DR) of 3.69 (2.78–4.91) and tumor recurrence risk (TRR) of 2.95 (2.24–3.88). The po-TACE therapy can efficiently improve their prognosis [DR = 0.59 (0.46–0.76), TRR = 0.63 (0.49–0.82)]. Interestingly, this improving role was more noticeable among these patients with high ADAs [DR = 0.36 (0.24–0.53), TRR = 0.40 (0.28–0.59)], but not among those with low ADAs (P > 0.05). Conclusions: These results suggest that increasing ADAs in the cancerous tissues may be beneficial for po-TACE in ameliorating the survival of patients with HCC

Contraction and expansion dynamics: deciphering genomic underpinnings of growth rate and pathogenicity in Mycobacterium

BackgroundMycobacterium bacteria, encompassing both slow growth (SGM) and rapid growth mycobacteria (RGM), along with true pathogenic (TP), opportunistic pathogenic (OP), and non-pathogenic (NP) types, exhibit diverse phenotypes. Yet, the genetic underpinnings of these variations remain elusive.MethodsHere, We conducted a comprehensive comparative genomics study involving 53 Mycobacterium species to unveil the genomic drivers behind growth rate and pathogenicity disparities.ResultsOur core/pan-genome analysis highlighted 1,307 shared gene families, revealing an open pan-genome structure. A phylogenetic tree highlighted clear boundaries between SGM and RGM, as well as TP and other species. Gene family contraction emerged as the primary alteration associated with growth and pathogenicity transitions. Specifically, ABC transporters for amino acids and inorganic ions, along with quorum sensing genes, exhibited significant contractions in SGM species, potentially influencing their distinct traits. Conversely, TP strains displayed contraction in lipid and secondary metabolite biosynthesis and metabolism-related genes. Across the 53 species, we identified 26 core and 64 accessory virulence factors. Remarkably, TP and OP strains stood out for their expanded mycobactin biosynthesis and type VII secretion system gene families, pivotal for their pathogenicity.ConclusionOur findings underscore the importance of gene family contraction in nucleic acids, ions, and substance metabolism for host adaptation, while emphasizing the significance of virulence gene family expansion, including type VII secretion systems and mycobactin biosynthesis, in driving mycobacterial pathogenicity

Association between immunoglobulin G N-glycosylation and lupus nephritis in female patients with systemic lupus erythematosus: A case-control study

Background: Lupus nephritis (LN) is a crucial complication of systemic lupus erythematosus (SLE) and has important clinical implications in guiding treatment. N-glycosylation of immunoglobulin G (IgG) plays a key role in the development of SLE by affecting the balance of anti-inflammatory and proinflammatory responses. This study aimed to evaluate the performance of IgG N-glycosylation for diagnosing LN in a sample of female SLE patients. Methods: This case-control study recruited 188 women with SLE, including 94 patients with LN and 94 age-matched patients without LN. The profiles of plasma IgG N-glycans were detected by hydrophilic interaction chromatography with ultra-performance liquid chromatography (HILIC-UPLC). A multivariate logistic regression model was used to explore the associations between IgG N-glycans and LN. A diagnostic model was developed using the significant glycans as well as demographic factors. The performance of IgG N-glycans in the diagnosis of LN was evaluated by receiver operating characteristic (ROC) curve analysis, and the area under the curve (AUC) and its 95% confidence interval (CI) were calculated. Results: There were significant differences in 9 initial glycans (GP2, GP4, GP6, GP8, GP10, GP14, GP16, GP18 and GP23) between women with SLE with and without LN (P \u3c 0.05). The levels of sialylated, galactosylated and fucosylated glycans were significantly lower in the LN patients than in the control group, while bisected N-acetylglucosamine (GlcNAc) glycans were increased in LN patients (P \u3c 0.05). GP8, GP10, GP18, and anemia were included in our diagnostic model, which performed well in differentiating female SLE patients with LN from those without LN (AUC = 0.792, 95% CI: 0.727 to 0.858). Conclusion: Our findings indicate that decreased sialylation, galactosylation, and core fucosylation and increased bisecting GlcNAc might play a role in the development of LN by upregulating the proinflammatory response of IgG. IgG N-glycans can serve as potential biomarkers to differentiate individuals with LN among SLE patients

A Simple Standard for Sharing Ontological Mappings (SSSOM).

Despite progress in the development of standards for describing and exchanging scientific information, the lack of easy-to-use standards for mapping between different representations of the same or similar objects in different databases poses a major impediment to data integration and interoperability. Mappings often lack the metadata needed to be correctly interpreted and applied. For example, are two terms equivalent or merely related? Are they narrow or broad matches? Or are they associated in some other way? Such relationships between the mapped terms are often not documented, which leads to incorrect assumptions and makes them hard to use in scenarios that require a high degree of precision (such as diagnostics or risk prediction). Furthermore, the lack of descriptions of how mappings were done makes it hard to combine and reconcile mappings, particularly curated and automated ones. We have developed the Simple Standard for Sharing Ontological Mappings (SSSOM) which addresses these problems by: (i) Introducing a machine-readable and extensible vocabulary to describe metadata that makes imprecision, inaccuracy and incompleteness in mappings explicit. (ii) Defining an easy-to-use simple table-based format that can be integrated into existing data science pipelines without the need to parse or query ontologies, and that integrates seamlessly with Linked Data principles. (iii) Implementing open and community-driven collaborative workflows that are designed to evolve the standard continuously to address changing requirements and mapping practices. (iv) Providing reference tools and software libraries for working with the standard. In this paper, we present the SSSOM standard, describe several use cases in detail and survey some of the existing work on standardizing the exchange of mappings, with the goal of making mappings Findable, Accessible, Interoperable and Reusable (FAIR). The SSSOM specification can be found at http://w3id.org/sssom/spec. Database URL: http://w3id.org/sssom/spec

Co-simulation with OpenAlea and GroIMP for cross-platform functional-structural plant modelling

International audienceIntroduction - Within the FSPM community, different teams of researchers have specialized on different processes. Thus there is an increasing wish to re-use the diverse simulation packages which were already created but which are usually implemented within different software environments, often not directly compatible with each other. The OpenAlea platform (Pradal et al., 2008) was developed as an environment to connect and reuse components with specific functionality in a scientific workflow environment. However, not all widely-used FSPM-related tools are already available from OpenAlea. In our work, we created an interface between OpenAlea and the FSPM platform GroIMP (Kniemeyer, 2008). The latter contains some dedicated tools, among them a simulator for light distribution and interception, based on stochastic path tracing. This radiation model is interesting due to its accuracy, its spectral capabilities and because it is already used in different applications. To demonstrate the technical usability of our interface, we took an established simulator for the growth and structural development of apple trees, MAppleT (Costes et al., 2008), which is already accessible from OpenAlea but which does not include a radiation model on its own. By exporting the generated tree structures from MAppleT via OpenAlea to GroIMP, we were able to employ GroIMP's light model on them and to reimport the structures with added information on "absorbed light" at phytomer level. Within OpenAlea, photosynthesis was then calculated and tentatively assumed effects on organ sizes could be visualized. Our conceptual contributions are a generic web architecture and the bidirectional matching between two different multiscale formalisms for topology and geometry in FSPMs. OpenAlea - OpenAlea emphasizes modularity and reuse by using a central data structure, the MTG (Godin and Caraglio, 1998). This enables indirect communication between the components that are integrated in the platform, using a blackboard architecture. It captures the multiscale organization of plant canopies, particularly its topology. Various properties can also be stored at the different scales. MTG vertices are topological elements that represent modular parts of a plant (e.g., axis, phytomer, organ). The neighborhood of each element is stored in the MTG as well as its associated properties. Geometrical elements are stored separately in an external scene graph for efficiency but are available from a property of the MTG. GroIMP - In GroIMP, a scene, including virtual plants, is represented as a rooted graph which can be an MTG in the sense of Godin and Caraglio (1998). At the same time, it has the semantics of a scene graph (a well-known data model in computer graphics). In contrast to the MTG in OpenAlea, it contains all information about the scene including geometry. Its nodes can represent geometrical objects (e.g., standing for plant organs), light sources, spatial transformations (e.g., rotations), or they are abstract nodes used purely for replacement purposes during development. The development of scenes, including plants, is modelled by parallel graph rewriting: Rules are applied by substituting in every timestep all instances of graphs which occur as left-hand side of a rule by the corresponding right-hand side. L-systems, operating on strings, can be subsumed as special cases under this formalism. The Interface - Although the data models of OpenAlea and GroIMP were both derived from the same mathematical concept, the implemented data structures of both platforms differ in several aspects. To bridge the gap between them, a data extractor from OpenAlea to GroIMP has first to combine the topological (MTG) with the geometrical information and to build a scene graph where the global positional information of each object is split into the transformation matrices of its predecessors (in the graph) and of itself. Furthermore, the scale information, represented by an indexing of nodes in OpenAlea, must be evaluated to build decomposition edges between all node pairs where a direct "is-part-of" relationship shall exist in the GroIMP graph. An extractor for the reverse data flow, from GroIMP to OpenAlea, faces another problem: since the GroIMP graph can contain cycles in the general case, a spanning tree has first to be derived within each scale level to be able to form a valid MTG on OpenAlea. Our graph model for data exchange is a canonical data model that makes the interoperability infrastructure independent from any specific FSPMs. It is a rooted, directed graph with typed nodes and thus more generic than an MTG. Technically, our connecting software tool consists of a client-side interface on top of OpenAlea and a server-side interface on top of GroIMP. An XML based data exchange format called XEG specified from the generic data exchange graph model is provided for the integration. Details are given by Long (2019). Results and Discussion - In a case study, we have applied our interface to provide an integration of the MAppleT model (Costes et al., 2008), that simulates apple tree growth and development based on stochastics and biomechanics and which is accessible via OpenAlea, with a light interception model based on stochastic pathtracing implemented within GroIMP. The objective was to get a bi-platform FSPM that simulates growth by taking local light interception into account. The workflow is as follows: Through the client-side interface the MTG generated by MAppleT is translated to an XEG graph, which is then packed to a message for transmission to the light interception model which resides remotely (on GroIMP). Through the server-side interface, the message is received, unpacked and translated into a GroIMP graph, forming the input of the light interception model. Then, update rules are applied which change a property "absorbed light" of nodes representing geometrical objects, according to the raytracing results. Through the server-side interface, the result is translated to a data frame in XEG packed to be sent back to OpenAlea (respectively, MAppleT) to complete the cross-platform simulation. Through the client-side interface, the data is unpacked and translated to Open- Alea as an MTG. Here, as growth in MAppleT is originally not based on light, we have as a first attempt applied an ad-hoc computation of biomass based directly on the intercepted light. The growth of an apple fruit then depends on the new biomass and thus on the light values from GroIMP. Botanically, this scenario is certainly not realistic since it disregards any translocation of assimilates, but it proves technical usability of the interface. Acknowledgements - Parts of this work were funded by DFG and ANR in the joint project "Multiscale functional-structural plant modelling at the example of apple trees", DFG grant number KU 847/11-1

Co-simulation with OpenAlea and GroIMP for cross-platform functional-structural plant modelling

International audienceIntroduction - Within the FSPM community, different teams of researchers have specialized on different processes. Thus there is an increasing wish to re-use the diverse simulation packages which were already created but which are usually implemented within different software environments, often not directly compatible with each other. The OpenAlea platform (Pradal et al., 2008) was developed as an environment to connect and reuse components with specific functionality in a scientific workflow environment. However, not all widely-used FSPM-related tools are already available from OpenAlea. In our work, we created an interface between OpenAlea and the FSPM platform GroIMP (Kniemeyer, 2008). The latter contains some dedicated tools, among them a simulator for light distribution and interception, based on stochastic path tracing. This radiation model is interesting due to its accuracy, its spectral capabilities and because it is already used in different applications. To demonstrate the technical usability of our interface, we took an established simulator for the growth and structural development of apple trees, MAppleT (Costes et al., 2008), which is already accessible from OpenAlea but which does not include a radiation model on its own. By exporting the generated tree structures from MAppleT via OpenAlea to GroIMP, we were able to employ GroIMP's light model on them and to reimport the structures with added information on "absorbed light" at phytomer level. Within OpenAlea, photosynthesis was then calculated and tentatively assumed effects on organ sizes could be visualized. Our conceptual contributions are a generic web architecture and the bidirectional matching between two different multiscale formalisms for topology and geometry in FSPMs. OpenAlea - OpenAlea emphasizes modularity and reuse by using a central data structure, the MTG (Godin and Caraglio, 1998). This enables indirect communication between the components that are integrated in the platform, using a blackboard architecture. It captures the multiscale organization of plant canopies, particularly its topology. Various properties can also be stored at the different scales. MTG vertices are topological elements that represent modular parts of a plant (e.g., axis, phytomer, organ). The neighborhood of each element is stored in the MTG as well as its associated properties. Geometrical elements are stored separately in an external scene graph for efficiency but are available from a property of the MTG. GroIMP - In GroIMP, a scene, including virtual plants, is represented as a rooted graph which can be an MTG in the sense of Godin and Caraglio (1998). At the same time, it has the semantics of a scene graph (a well-known data model in computer graphics). In contrast to the MTG in OpenAlea, it contains all information about the scene including geometry. Its nodes can represent geometrical objects (e.g., standing for plant organs), light sources, spatial transformations (e.g., rotations), or they are abstract nodes used purely for replacement purposes during development. The development of scenes, including plants, is modelled by parallel graph rewriting: Rules are applied by substituting in every timestep all instances of graphs which occur as left-hand side of a rule by the corresponding right-hand side. L-systems, operating on strings, can be subsumed as special cases under this formalism. The Interface - Although the data models of OpenAlea and GroIMP were both derived from the same mathematical concept, the implemented data structures of both platforms differ in several aspects. To bridge the gap between them, a data extractor from OpenAlea to GroIMP has first to combine the topological (MTG) with the geometrical information and to build a scene graph where the global positional information of each object is split into the transformation matrices of its predecessors (in the graph) and of itself. Furthermore, the scale information, represented by an indexing of nodes in OpenAlea, must be evaluated to build decomposition edges between all node pairs where a direct "is-part-of" relationship shall exist in the GroIMP graph. An extractor for the reverse data flow, from GroIMP to OpenAlea, faces another problem: since the GroIMP graph can contain cycles in the general case, a spanning tree has first to be derived within each scale level to be able to form a valid MTG on OpenAlea. Our graph model for data exchange is a canonical data model that makes the interoperability infrastructure independent from any specific FSPMs. It is a rooted, directed graph with typed nodes and thus more generic than an MTG. Technically, our connecting software tool consists of a client-side interface on top of OpenAlea and a server-side interface on top of GroIMP. An XML based data exchange format called XEG specified from the generic data exchange graph model is provided for the integration. Details are given by Long (2019). Results and Discussion - In a case study, we have applied our interface to provide an integration of the MAppleT model (Costes et al., 2008), that simulates apple tree growth and development based on stochastics and biomechanics and which is accessible via OpenAlea, with a light interception model based on stochastic pathtracing implemented within GroIMP. The objective was to get a bi-platform FSPM that simulates growth by taking local light interception into account. The workflow is as follows: Through the client-side interface the MTG generated by MAppleT is translated to an XEG graph, which is then packed to a message for transmission to the light interception model which resides remotely (on GroIMP). Through the server-side interface, the message is received, unpacked and translated into a GroIMP graph, forming the input of the light interception model. Then, update rules are applied which change a property "absorbed light" of nodes representing geometrical objects, according to the raytracing results. Through the server-side interface, the result is translated to a data frame in XEG packed to be sent back to OpenAlea (respectively, MAppleT) to complete the cross-platform simulation. Through the client-side interface, the data is unpacked and translated to Open- Alea as an MTG. Here, as growth in MAppleT is originally not based on light, we have as a first attempt applied an ad-hoc computation of biomass based directly on the intercepted light. The growth of an apple fruit then depends on the new biomass and thus on the light values from GroIMP. Botanically, this scenario is certainly not realistic since it disregards any translocation of assimilates, but it proves technical usability of the interface. Acknowledgements - Parts of this work were funded by DFG and ANR in the joint project "Multiscale functional-structural plant modelling at the example of apple trees", DFG grant number KU 847/11-1

Design of a multi-epitope vaccine against goatpox virus using an immunoinformatics approach

IntroductionGoatpox, a severe infectious disease caused by goatpox virus (GTPV), leads to enormous economic losses in the livestock industry. Traditional live attenuated vaccines cause serious side effects and exist a risk of dispersal. Therefore, it is urgent to develop efficient and safer vaccines to prevent and control of GTPV.MethodsIn the present study, we are aimed to design a multi-epitope subunit vaccine against GTPV using an immunoinformatics approach. Various immunodominant cytotoxic T lymphocytes (CTL) epitopes, helper T lymphocytes (HTL) epitopes, and B-cell epitopes from P32, L1R, and 095 proteins of GTPV were screened and liked by the AAY, GPGPG, and KK connectors, respectively. Furthermore, an adjuvant β-defensin was attached to the vaccine’s N-terminal using the EAAAK linker to enhance immunogenicity.ResultsThe constructed vaccine was soluble, non-allergenic and non-toxic and exhibited high levels of antigenicity and immunogenicity. The vaccine’s 3D structure was subsequently predicted, refined and validated, resulting in an optimized model with a Z-value of -3.4. Molecular docking results demonstrated that the vaccine had strong binding affinity with TLR2(-27.25 kcal/mol), TLR3(-39.84 kcal/mol), and TLR4(-59.42 kcal/mol). Molecular dynamics simulation results indicated that docked vaccine-TLR complexes were stable. Immune simulation analysis suggested that the vaccine can induce remarkable increase in antibody titers of IgG and IgM, higher levels of IFN-γ and IL-2.ConclusionThe designed GTPV multi-epitope vaccine is structurally stable and can induce robust humoral and cellular immune responses, which may be a promising vaccine candidate against GTPV

D3.3.1 Metadata schema extension for archival systems ; DURAARK - Durable Architectural Knowledge ; FP7 - ICT - Digital Preservation

In this report strategies are outlined how relevant metadata for the digital preservation of architectural data and related external vocabularies can be structured and stored. Related requirements are identified in WP7, further specified in WP2 and documented in the deliverables D 2.2.1, D.2.2.2, D.2.2.3 (Requirements documents) and D.7.7.1. Metadata for data identified relevant within the scope of the DURAARK project will be captured in OWL/RDF metadata schemas that re-use existing and recognized metadata standards and only extend them where deemed necessary. The proposed domain-specific metadata structures cover three main aspects: Descriptive metadata that stores domain-specific summaries and classification information of buildings as an intellectual entity type in a LTP system. Technical metadata that captures information about Building Information Models (BIM’s) and point cloud models which are the two main representation forms of buildings the DURAARK project focuses on. Linked Data metadata that captures information about the vocabularies and datasets that are used for the semantic enrichment of building models. These are stored separately alongside the individual building model Information Packages (IP) in the archive in a Semantic Digital Archive (SDA) for the storage and a Semantic Digital Observatory (SDO) for the processing of such volatile, evolving data. The use of this metadata from IFC models and inference methods are described in generic vendor-neutral terms and exemplified as an extension implementation to the existing archival system. The suggested reuse of existing schemas and vocabularies is illustrated in a number of use cases in section 4. In the appendices of this document complete listings of the respective vocabularies and schemas are provided. The results of this document have been created in collaboration with the work and deliverables in other work packages and specifically with work packages 2 and 7