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

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

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

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

An Architecture for the Integration of Different Functional and Structural Plant Models

International audiencePlant scientists use Functional Structural Plant Models (FSPMs) to model plant systems within a limited space-time range. To allow FSPMs to abstract complex plant systems beyond a single model's limitation, an integration that compounds different FSPMs could be a possible solution. However, the integration involves many technical dimensions and a generic software infrastructure for all integration cases is not possible. In this paper, we analyze the requirements of the integration with all the technical dimensions. Instead of an infrastructure, we propose a generic architecture with specific process-related components as a logical level solution by combining an ETL (Extract, Transform and Load) based sub architecture and a C/S (Client/Server) based sub architecture. This allows the integration of different FSP models hosted on the same and different FSP modeling platforms in a flexible way. We demonstrate the usability of the architecture by the implementation of a full infrastructure for the integration of two specific FSPMs, and we illustrate the effectiveness of the infrastructure by several integrative tests. CCS Concepts • Software and its engineering➝Integration frameworks, Software and its engineering➝Cooperating communicating processes, Software and its engineering➝Data flow architectures Keywords Functional structural plant model; simulation; multiscale; Multiscale tree graph; OpenAlea and GroIMP platform

Sci Data

Grape quality is regulated by complex interactions between environments and cultivars. Growing suitable cultivars in a given region is essential for maintaining viticulture sustainability, particularly in the face of climate change. We created a database composed of three different subsets of data. The first subset was created by digitizing and curating the seminal report of Amerine and Winkler (1944), which provided grape harvest dates (GHDs), the quality of musts and wines, and wine tasting notes for 148 cultivars from 1935–1941 across five contrasting climatic regions of California. To put this dataset into a climate change context, we collected GHDs and must sugar content (°Brix) records from 1991 to 2018 for four representative cultivars in one of the five studied regions (Napa). Finally, we integrated meteorological data of the five regions during 1911–2018 and calculated bioclimatic indices important for grape. The resulting database is unique and valuable for assessing the fitness between cultivars across environments in order to mitigate the effects of climate change.Design Type(s)Cultivars design • Regions designMeasurement Type(s)Climate data • Harvest date • Quality • Tasting notesTechnology Type(s)Phenology characterization • Quality determinationSample Characteristic(s)Grape harvest dates • °Brix • Tannin • Total acid • pH • Alcohol • Fixed acid • ExtractMeasurement(s)maximum air temperature • minimum air temperature • total soluble solids (oBrix) • must total acid • must pH • wine alcohol • wine extract • wine tannin • wine total acid • wine volatile acidTechnology Type(s)weather station • a oBrix hydrometer • titration with sodium hydroxide to a phenolphthalein end point • a quinhydrone electrode or a Beckman pH meter • hydrometer • a special 0° to 8° Balling hydrometer • the Association of Official Agricultural Chemists method • titration with phenolphthalein as an indicator • titration with pretreated wines by method II of the Association of Official Agricultural Chemist