The Threads of Biosystems Engineering

The core concepts, or threads, of Biosystems Engineering (BSEN) are variously understood by those within the discipline, but have never been unequivocally defined due to its early stage of development. This makes communication and teaching difficult compared to other well established engineering subjects. Biosystems Engineering is a field of Engineering which int egrates engineering science and design with applied biological, environmental and agricultural sciences. It represents an evolution of the Agricultural Engineering discipline applied to all living organisms not including biomedical applications. The basic key element for the emerging EU Biosystems Engineering program of studies is to ensure that it offers essential minimum fundamental engine ering knowledge and competences . A core curriculum developed by Erasmus Thematic Networks is used as benchmark for Agr icultural and Biosystems Engineering studies in Europe. The common basis of the core curriculum for the discipline across the Atlantic , including a minimum of competences comprising the Biosystems Engineering core competencies, has been defined by an Atlan tis project , but this needs to be taken further by defining the threads linking courses together. This paper presents a structured approach to define the Threads of BSEN . The definition of the mid-level competences and the associated learning outcomes has been one of the objectives of the Atlantis programme TABE.NET. The mid-level competences and learning outcomes for each of six specializations of BSEN are defined while the domain-specific knowledge to be acquired for each outcome is proposed. Once the proposed definitions are adopted, these threads will be available for global development of the BSEN.

A model to develop a platform for personalised health applications

Antecedentes Europa vive una situación insostenible. Desde el 2008 se han reducido los recursos de los gobiernos a raíz de la crisis económica. El continente Europeo envejece con ritmo constante al punto que se prevé que en 2050 habrá sólo dos trabajadores por jubilado [54]. A esta situación se le añade el aumento de la incidencia de las enfermedades crónicas, relacionadas con el envejecimiento, cuyo coste puede alcanzar el 7% del PIB de un país [51]. Es necesario un cambio de paradigma. Una nueva manera de cuidar de la salud de las personas: sustentable, eficaz y preventiva más que curativa. Algunos estudios abogan por el cuidado personalizado de la salud (pHealth). En este modelo las prácticas médicas son adaptadas e individualizadas al paciente, desde la detección de los factores de riesgo hasta la personalización de los tratamientos basada en la respuesta del individuo [81]. El cuidado personalizado de la salud está asociado a menudo al uso de las tecnologías de la información y comunicación (TICs) que, con su desarrollo exponencial, ofrecen oportunidades interesantes para la mejora de la salud. El cambio de paradigma hacia el pHealth está lentamente ocurriendo, tanto en el ámbito de la investigación como en la industria, pero todavía no de manera significativa. Existen todavía muchas barreras relacionadas a la economía, a la política y la cultura. También existen barreras puramente tecnológicas, como la falta de sistemas de información interoperables [199]. A pesar de que los aspectos de interoperabilidad están evolucionando, todavía hace falta un diseño de referencia especialmente direccionado a la implementación y el despliegue en gran escala de sistemas basados en pHealth. La presente Tesis representa un intento de organizar la disciplina de la aplicación de las TICs al cuidado personalizado de la salud en un modelo de referencia, que permita la creación de plataformas de desarrollo de software para simplificar tareas comunes de desarrollo en este dominio. Preguntas de investigación RQ1 >Es posible definir un modelo, basado en técnicas de ingeniería del software, que represente el dominio del cuidado personalizado de la salud de una forma abstracta y representativa? RQ2 >Es posible construir una plataforma de desarrollo basada en este modelo? RQ3 >Esta plataforma ayuda a los desarrolladores a crear sistemas pHealth complejos e integrados? Métodos Para la descripción del modelo se adoptó el estándar ISO/IEC/IEEE 42010por ser lo suficientemente general y abstracto para el amplio enfoque de esta tesis [25]. El modelo está definido en varias partes: un modelo conceptual, expresado a través de mapas conceptuales que representan las partes interesadas (stakeholders), los artefactos y la información compartida; y escenarios y casos de uso para la descripción de sus funcionalidades. El modelo fue desarrollado de acuerdo a la información obtenida del análisis de la literatura, incluyendo 7 informes industriales y científicos, 9 estándares, 10 artículos en conferencias, 37 artículos en revistas, 25 páginas web y 5 libros. Basándose en el modelo se definieron los requisitos para la creación de la plataforma de desarrollo, enriquecidos por otros requisitos recolectados a través de una encuesta realizada a 11 ingenieros con experiencia en la rama. Para el desarrollo de la plataforma, se adoptó la metodología de integración continua [74] que permitió ejecutar tests automáticos en un servidor y también desplegar aplicaciones en una página web. En cuanto a la metodología utilizada para la validación se adoptó un marco para la formulación de teorías en la ingeniería del software [181]. Esto requiere el desarrollo de modelos y proposiciones que han de ser validados dentro de un ámbito de investigación definido, y que sirvan para guiar al investigador en la búsqueda de la evidencia necesaria para justificarla. La validación del modelo fue desarrollada mediante una encuesta online en tres rondas con un número creciente de invitados. El cuestionario fue enviado a 134 contactos y distribuido en algunos canales públicos como listas de correo y redes sociales. El objetivo era evaluar la legibilidad del modelo, su nivel de cobertura del dominio y su potencial utilidad en el diseño de sistemas derivados. El cuestionario incluía preguntas cuantitativas de tipo Likert y campos para recolección de comentarios. La plataforma de desarrollo fue validada en dos etapas. En la primera etapa se utilizó la plataforma en un experimento a pequeña escala, que consistió en una sesión de entrenamiento de 12 horas en la que 4 desarrolladores tuvieron que desarrollar algunos casos de uso y reunirse en un grupo focal para discutir su uso. La segunda etapa se realizó durante los tests de un proyecto en gran escala llamado HeartCycle [160]. En este proyecto un equipo de diseñadores y programadores desarrollaron tres aplicaciones en el campo de las enfermedades cardio-vasculares. Una de estas aplicaciones fue testeada en un ensayo clínico con pacientes reales. Al analizar el proyecto, el equipo de desarrollo se reunió en un grupo focal para identificar las ventajas y desventajas de la plataforma y su utilidad. Resultados Por lo que concierne el modelo que describe el dominio del pHealth, la parte conceptual incluye una descripción de los roles principales y las preocupaciones de los participantes, un modelo de los artefactos TIC que se usan comúnmente y un modelo para representar los datos típicos que son necesarios formalizar e intercambiar entre sistemas basados en pHealth. El modelo funcional incluye un conjunto de 18 escenarios, repartidos en: punto de vista de la persona asistida, punto de vista del cuidador, punto de vista del desarrollador, punto de vista de los proveedores de tecnologías y punto de vista de las autoridades; y un conjunto de 52 casos de uso repartidos en 6 categorías: actividades de la persona asistida, reacciones del sistema, actividades del cuidador, \engagement" del usuario, actividades del desarrollador y actividades de despliegue. Como resultado del cuestionario de validación del modelo, un total de 65 personas revisó el modelo proporcionando su nivel de acuerdo con las dimensiones evaluadas y un total de 248 comentarios sobre cómo mejorar el modelo. Los conocimientos de los participantes variaban desde la ingeniería del software (70%) hasta las especialidades médicas (15%), con declarado interés en eHealth (24%), mHealth (16%), Ambient Assisted Living (21%), medicina personalizada (5%), sistemas basados en pHealth (15%), informática médica (10%) e ingeniería biomédica (8%) con una media de 7.25_4.99 años de experiencia en estas áreas. Los resultados de la encuesta muestran que los expertos contactados consideran el modelo fácil de leer (media de 1.89_0.79 siendo 1 el valor más favorable y 5 el peor), suficientemente abstracto (1.99_0.88) y formal (2.13_0.77), con una cobertura suficiente del dominio (2.26_0.95), útil para describir el dominio (2.02_0.7) y para generar sistemas más específicos (2_0.75). Los expertos también reportan un interés parcial en utilizar el modelo en su trabajo (2.48_0.91). Gracias a sus comentarios, el modelo fue mejorado y enriquecido con conceptos que faltaban, aunque no se pudo demonstrar su mejora en las dimensiones evaluadas, dada la composición diferente de personas en las tres rondas de evaluación. Desde el modelo, se generó una plataforma de desarrollo llamada \pHealth Patient Platform (pHPP)". La plataforma desarrollada incluye librerías, herramientas de programación y desarrollo, un tutorial y una aplicación de ejemplo. Se definieron cuatro módulos principales de la arquitectura: el Data Collection Engine, que permite abstraer las fuentes de datos como sensores o servicios externos, mapeando los datos a bases de datos u ontologías, y permitiendo interacción basada en eventos; el GUI Engine, que abstrae la interfaz de usuario en un modelo de interacción basado en mensajes; y el Rule Engine, que proporciona a los desarrolladores un medio simple para programar la lógica de la aplicación en forma de reglas \if-then". Después de que la plataforma pHPP fue utilizada durante 5 años en el proyecto HeartCycle, 5 desarrolladores fueron reunidos en un grupo de discusión para analizar y evaluar la plataforma. De estas evaluaciones se concluye que la plataforma fue diseñada para encajar las necesidades de los ingenieros que trabajan en la rama, permitiendo la separación de problemas entre las distintas especialidades, y simplificando algunas tareas de desarrollo como el manejo de datos y la interacción asíncrona. A pesar de ello, se encontraron algunos defectos a causa de la inmadurez de algunas tecnologías empleadas, y la ausencia de algunas herramientas específicas para el dominio como el procesado de datos o algunos protocolos de comunicación relacionados con la salud. Dentro del proyecto HeartCycle la plataforma fue utilizada para el desarrollo de la aplicación \Guided Exercise", un sistema TIC para la rehabilitación de pacientes que han sufrido un infarto del miocardio. El sistema fue testeado en un ensayo clínico randomizado en el cual a 55 pacientes se les dio el sistema para su uso por 21 semanas. De los resultados técnicos del ensayo se puede concluir que, a pesar de algunos errores menores prontamente corregidos durante el estudio, la plataforma es estable y fiable. Conclusiones La investigación llevada a cabo en esta Tesis y los resultados obtenidos proporcionan las respuestas a las tres preguntas de investigación que motivaron este trabajo: RQ1 Se ha desarrollado un modelo para representar el dominio de los sistemas personalizados de salud. La evaluación hecha por los expertos de la rama concluye que el modelo representa el dominio con precisión y con un balance apropiado entre abstracción y detalle. RQ2 Se ha desarrollado, con éxito, una plataforma de desarrollo basada en el modelo. RQ3 Se ha demostrado que la plataforma es capaz de ayudar a los desarrolladores en la creación de software pHealth complejos. Las ventajas de la plataforma han sido demostradas en el ámbito de un proyecto de gran escala, aunque el enfoque genérico adoptado indica que la plataforma podría ofrecer beneficios también en otros contextos. Los resultados de estas evaluaciones ofrecen indicios de que, ambos, el modelo y la plataforma serán buenos candidatos para poderse convertir en una referencia para futuros desarrollos de sistemas pHealth. ABSTRACT Background Europe is living in an unsustainable situation. The economic crisis has been reducing governments' economic resources since 2008 and threatening social and health systems, while the proportion of older people in the European population continues to increase so that it is foreseen that in 2050 there will be only two workers per retiree [54]. To this situation it should be added the rise, strongly related to age, of chronic diseases the burden of which has been estimated to be up to the 7% of a country's gross domestic product [51]. There is a need for a paradigm shift, the need for a new way of caring for people's health, shifting the focus from curing conditions that have arisen to a sustainable and effective approach with the emphasis on prevention. Some advocate the adoption of personalised health care (pHealth), a model where medical practices are tailored to the patient's unique life, from the detection of risk factors to the customization of treatments based on each individual's response [81]. Personalised health is often associated to the use of Information and Communications Technology (ICT), that, with its exponential development, offers interesting opportunities for improving healthcare. The shift towards pHealth is slowly taking place, both in research and in industry, but the change is not significant yet. Many barriers still exist related to economy, politics and culture, while others are purely technological, like the lack of interoperable information systems [199]. Though interoperability aspects are evolving, there is still the need of a reference design, especially tackling implementation and large scale deployment of pHealth systems. This thesis contributes to organizing the subject of ICT systems for personalised health into a reference model that allows for the creation of software development platforms to ease common development issues in the domain. Research questions RQ1 Is it possible to define a model, based on software engineering techniques, for representing the personalised health domain in an abstract and representative way? RQ2 Is it possible to build a development platform based on this model? RQ3 Does the development platform help developers create complex integrated pHealth systems? Methods As method for describing the model, the ISO/IEC/IEEE 42010 framework [25] is adopted for its generality and high level of abstraction. The model is specified in different parts: a conceptual model, which makes use of concept maps, for representing stakeholders, artefacts and shared information, and in scenarios and use cases for the representation of the functionalities of pHealth systems. The model was derived from literature analysis, including 7 industrial and scientific reports, 9 electronic standards, 10 conference proceedings papers, 37 journal papers, 25 websites and 5 books. Based on the reference model, requirements were drawn for building the development platform enriched with a set of requirements gathered in a survey run among 11 experienced engineers. For developing the platform, the continuous integration methodology [74] was adopted which allowed to perform automatic tests on a server and also to deploy packaged releases on a web site. As a validation methodology, a theory building framework for SW engineering was adopted from [181]. The framework, chosen as a guide to find evidence for justifying the research questions, imposed the creation of theories based on models and propositions to be validated within a scope. The validation of the model was conducted as an on-line survey in three validation rounds, encompassing a growing number of participants. The survey was submitted to 134 experts of the field and on some public channels like relevant mailing lists and social networks. Its objective was to assess the model's readability, its level of coverage of the domain and its potential usefulness in the design of actual, derived systems. The questionnaires included quantitative Likert scale questions and free text inputs for comments. The development platform was validated in two scopes. As a small-scale experiment, the platform was used in a 12 hours training session where 4 developers had to perform an exercise consisting in developing a set of typical pHealth use cases At the end of the session, a focus group was held to identify benefits and drawbacks of the platform. The second validation was held as a test-case study in a large scale research project called HeartCycle the aim of which was to develop a closed-loop disease management system for heart failure and coronary heart disease patients [160]. During this project three applications were developed by a team of programmers and designers. One of these applications was tested in a clinical trial with actual patients. At the end of the project, the team was interviewed in a focus group to assess the role the platform had within the project. Results For what regards the model that describes the pHealth domain, its conceptual part includes a description of the main roles and concerns of pHealth stakeholders, a model of the ICT artefacts that are commonly adopted and a model representing the typical data that need to be formalized among pHealth systems. The functional model includes a set of 18 scenarios, divided into assisted person's view, caregiver's view, developer's view, technology and services providers' view and authority's view, and a set of 52 Use Cases grouped in 6 categories: assisted person's activities, system reactions, caregiver's activities, user engagement, developer's activities and deployer's activities. For what concerns the validation of the model, a total of 65 people participated in the online survey providing their level of agreement in all the assessed dimensions and a total of 248 comments on how to improve and complete the model. Participants' background spanned from engineering and software development (70%) to medical specialities (15%), with declared interest in the fields of eHealth (24%), mHealth (16%), Ambient Assisted Living (21%), Personalized Medicine (5%), Personal Health Systems (15%), Medical Informatics (10%) and Biomedical Engineering (8%) with an average of 7.25_4.99 years of experience in these fields. From the analysis of the answers it is possible to observe that the contacted experts considered the model easily readable (average of 1.89_0.79 being 1 the most favourable scoring and 5 the worst), sufficiently abstract (1.99_0.88) and formal (2.13_0.77) for its purpose, with a sufficient coverage of the domain (2.26_0.95), useful for describing the domain (2.02_0.7) and for generating more specific systems (2_0.75) and they reported a partial interest in using the model in their job (2.48_0.91). Thanks to their comments, the model was improved and enriched with concepts that were missing at the beginning, nonetheless it was not possible to prove an improvement among the iterations, due to the diversity of the participants in the three rounds. From the model, a development platform for the pHealth domain was generated called pHealth Patient Platform (pHPP). The platform includes a set of libraries, programming and deployment tools, a tutorial and a sample application. The main four modules of the architecture are: the Data Collection Engine, which allows abstracting sources of information like sensors or external services, mapping data to databases and ontologies, and allowing event-based interaction and filtering, the GUI Engine, which abstracts the user interface in a message-like interaction model, the Workow Engine, which allows programming the application's user interaction ows with graphical workows, and the Rule Engine, which gives developers a simple means for programming the application's logic in the form of \if-then" rules. After the 5 years experience of HeartCycle, partially programmed with pHPP, 5 developers were joined in a focus group to discuss the advantages and drawbacks of the platform. The view that emerged from the training course and the focus group was that the platform is well-suited to the needs of the engineers working in the field, it allowed the separation of concerns among the different specialities and it simplified some common development tasks like data management and asynchronous interaction. Nevertheless, some deficiencies were pointed out in terms of a lack of maturity of some technological choices, and for the absence of some domain-specific tools, e.g. for data processing or for health-related communication protocols. Within HeartCycle, the platform was used to develop part of the Guided Exercise system, a composition of ICT tools for the physical rehabilitation of patients who suffered from myocardial infarction. The system developed using the platform was tested in a randomized controlled clinical trial, in which 55 patients used the system for 21 weeks. The technical results of this trial showed that the system was stable and reliable. Some minor bugs were detected, but these were promptly corrected using the platform. This shows that the platform, as well as facilitating the development task, can be successfully used to produce reliable software. Conclusions The research work carried out in developing this thesis provides responses to the three three research questions that were the motivation for the work. RQ1 A model was developed representing the domain of personalised health systems, and the assessment of experts in the field was that it represents the domain accurately, with an appropriate balance between abstraction and detail. RQ2 A development platform based on the model was successfully developed. RQ3 The platform has been shown to assist developers create complex pHealth software. This was demonstrated within the scope of one large-scale project, but the generic approach adopted provides indications that it would offer benefits more widely. The results of these evaluations provide indications that both the model and the platform are good candidates for being a reference for future pHealth developments.

Knowledge-based spatiotemporal linear abstraction

We present a theoretical framework and a case study for reusing the same conceptual and computational methodology for both temporal abstraction and linear (unidimensional) space abstraction, in a domain (evaluation of traffic-control actions) significantly different from the one (clinical medicine) in which the method was originally used. The method, known as knowledge-based temporal abstraction, abstracts high-level concepts and patterns from time-stamped raw data using a formal theory of domain-specific temporal-abstraction knowledge. We applied this method, originally used to interpret time-oriented clinical data, to the domain of traffic control, in which the monitoring task requires linear pattern matching along both space and time. First, we reused the method for creation of unidimensional spatial abstractions over highways, given sensor measurements along each highway measured at the same time point. Second, we reused the method to create temporal abstractions of the traffic behavior, for the same space segments, but during consecutive time points. We defined the corresponding temporal-abstraction and spatial-abstraction domain-specific knowledge. Our results suggest that (1) the knowledge-based temporal-abstraction method is reusable over time and unidimensional space as well as over significantly different domains; (2) the method can be generalized into a knowledge-based linear-abstraction method, which solves tasks requiring abstraction of data along any linear distance measure; and (3) a spatiotemporal-abstraction method can be assembled from two copies of the generalized method and a spatial-decomposition mechanism, and is applicable to tasks requiring abstraction of time-oriented data into meaningful spatiotemporal patterns over a linear, decomposable space, such as traffic over a set of highways.

SMART Protocols: seMAntic represenTation for experimental protocols

Two important characteristics of science are the ?reproducibility? and ?clarity?. By rigorous practices, scientists explore aspects of the world that they can reproduce under carefully controlled experimental conditions. The clarity, complementing reproducibility, provides unambiguous descriptions of results in a mechanical or mathematical form. Both pillars depend on well-structured and accurate descriptions of scientific practices, which are normally recorded in experimental protocols, scientific workflows, etc. Here we present SMART Protocols (SP), our ontology-based approach for representing experimental protocols and our contribution to clarity and reproducibility. SP delivers an unambiguous description of processes by means of which data is produced; by doing so, we argue, it facilitates reproducibility. Moreover, SP is thought to be part of e-science infrastructures. SP results from the analysis of 175 protocols; from this dataset, we extracted common elements. From our analysis, we identified document, workflow and domain-specific aspects in the representation of experimental protocols. The ontology is available at http://purl.org/net/SMARTprotocol

Desarrollo de una aplicación web orientada a la asistencia en el diseño de protocolos de biología sintética

Se plantea desarrollar una herramienta que ofrezca un soporte eficiente para la creación y el diseño de protocolos biológicos a los investigadores en biología sintética. Partiendo de este objetivo, se definen dos cometidos principales: Realizar un estudio de las herramientas existentes que ofrezcan soporte al diseño y aquellas pensadas para diseñar protocolos biológicos, el fin de este estudio es descubrir las funcionalidades que implementan estas herramientas para mejorarlas. Además, se ha de desarrollar una herramienta web que, mediante un lenguaje visual, permita diseñar y crear protocolos de biología sintética, guardándolos en un formato de archivo independiente del lenguaje. En este documento se encuentra, en primer lugar, la definición de objetivos y la descripción del método de desarrollo seguido durante la implementación del proyecto; después, el marco teórico, donde se exponen las herramientas estudiadas y las similitudes y diferencias con la idea que se tiene de la aplicación, y también las herramientas de desarrollo web con las que se va a implementar el proyecto. A continuación, se muestran los resultados obtenidos, mediante la definición de requisitos, así como una exposición de la propia herramienta. Por último, se encuentra la estrategia de validación que se ha seguido en el desarrollo del proyecto y se exponen las conclusiones obtenidas de estas validaciones; también se incluyen al final las conclusiones del proyecto y las líneas futuras de desarrollo.---ABSTRACT---It is planned to develop a tool that provides efficient support for the creation and design of biological protocols researchers in synthetic biology. Based on this goal, two main tasks are defined: Conduct a study of existing tools that provide design support and those intended to design biological protocols, the purpose of this study is to discover the functionalities that implement these tools to improve them. Furthermore, it has to develop a web tool that, through a visual language, allowing design and create synthetic biology protocols, storing them in an independent language file format. In this document is located, first, the definition of objectives and description of the development method followed during project implementation; then the theoretical framework where tools and studied the similarities and differences with the idea we have of the application are discussed, and development tools with which they will implement the project. Then the results obtained, by defining requirements as well as an exhibition of the own tool. Finally, the validation strategy that has been followed in the development of the project and the conclusions drawn from these validations are exposed; also, it is included at the end of the project conclusions and future lines of development.

Syndapin I, a Synaptic Dynamin-binding Protein that Associates with the Neural Wiskott-Aldrich Syndrome Protein

The GTPase dynamin has been clearly implicated in clathrin-mediated endocytosis of synaptic vesicle membranes at the presynaptic nerve terminal. Here we describe a novel 52-kDa protein in rat brain that binds the proline-rich C terminus of dynamin. Syndapin I (synaptic, dynamin-associated protein I) is highly enriched in brain where it exists in a high molecular weight complex. Syndapin I can be involved in multiple protein–protein interactions via a src homology 3 (SH3) domain at the C terminus and two predicted coiled-coil stretches. Coprecipitation studies and blot overlay analyses revealed that syndapin I binds the brain-specific proteins dynamin I, synaptojanin, and synapsin I via an SH3 domain-specific interaction. Coimmunoprecipitation of dynamin I with antibodies recognizing syndapin I and colocalization of syndapin I with dynamin I at vesicular structures in primary neurons indicate that syndapin I associates with dynamin I in vivo and may play a role in synaptic vesicle endocytosis. Furthermore, syndapin I associates with the neural Wiskott-Aldrich syndrome protein, an actin-depolymerizing protein that regulates cytoskeletal rearrangement. These characteristics of syndapin I suggest a molecular link between cytoskeletal dynamics and synaptic vesicle recycling in the nerve terminal.

A Novel Tetanus Neurotoxin-insensitive Vesicle-associated Membrane Protein in SNARE Complexes of the Apical Plasma Membrane of Epithelial Cells

The importance of soluble N-ethyl maleimide (NEM)-sensitive fusion protein (NSF) attachment protein (SNAP) receptors (SNAREs) in synaptic vesicle exocytosis is well established because it has been demonstrated that clostridial neurotoxins (NTs) proteolyze the vesicle SNAREs (v-SNAREs) vesicle-associated membrane protein (VAMP)/brevins and their partners, the target SNAREs (t-SNAREs) syntaxin 1 and SNAP25. Yet, several exocytotic events, including apical exocytosis in epithelial cells, are insensitive to numerous clostridial NTs, suggesting the presence of SNARE-independent mechanisms of exocytosis. In this study we found that syntaxin 3, SNAP23, and a newly identified VAMP/brevin, tetanus neurotoxin (TeNT)-insensitive VAMP (TI-VAMP), are insensitive to clostridial NTs. In epithelial cells, TI-VAMP–containing vesicles were concentrated in the apical domain, and the protein was detected at the apical plasma membrane by immunogold labeling on ultrathin cryosections. Syntaxin 3 and SNAP23 were codistributed at the apical plasma membrane where they formed NEM-dependent SNARE complexes with TI-VAMP and cellubrevin. We suggest that TI-VAMP, SNAP23, and syntaxin 3 can participate in exocytotic processes at the apical plasma membrane of epithelial cells and, more generally, domain-specific exocytosis in clostridial NT-resistant pathways.

Apical sorting of a voltage- and Ca2+-activated K+ channel α-subunit in Madin-Darby canine kidney cells is independent of N-glycosylation

The voltage- and Ca2+-activated K+ (KV,Ca) channel is expressed in a variety of polarized epithelial cells seemingly displaying a tissue-dependent apical-to-basolateral regionalization, as revealed by electrophysiology. Using domain-specific biotinylation and immunofluorescence we show that the human channel KV,Ca α-subunit (human Slowpoke channel, hSlo) is predominantly found in the apical plasma membrane domain of permanently transfected Madin-Darby canine kidney cells. Both the wild-type and a mutant hSlo protein lacking its only potential N-glycosylation site were efficiently transported to the cell surface and concentrated in the apical domain even when they were overexpressed to levels 200- to 300-fold higher than the density of intrinsic Slo channels. Furthermore, tunicamycin treatment did not prevent apical segregation of hSlo, indicating that endogenous glycosylated proteins (e.g., KV,Ca β-subunits) were not required. hSlo seems to display properties for lipid-raft targeting, as judged by its buoyant distribution in sucrose gradients after extraction with either detergent or sodium carbonate. The evidence indicates that the hSlo protein possesses intrinsic information for transport to the apical cell surface through a mechanism that may involve association with lipid rafts and that is independent of glycosylation of the channel itself or an associated protein. Thus, this particular polytopic model protein shows that glycosylation-independent apical pathways exist for endogenous membrane proteins in Madin-Darby canine kidney cells.

The Wheat Peptidyl Prolyl cis-trans-Isomerase FKBP77 Is Heat Induced and Developmentally Regulated1

We isolated a cDNA encoding a 568-amino acid, heat-stress-induced peptidyl prolyl isomerase belonging to the FK506-binding-protein (FKBP) family. The open reading frame encodes for a peptidyl prolyl isomerase that possesses three FKBP-12-like domains, a putative tetratricopeptide motif, and a calmodulin-binding domain. Specific antibodies showed that the open reading frame encodes a heat-induced 77-kD protein, the wheat FKBP77 (wFKBP77), which exhibits 84% identity with the wFKBP73 and 42% identity with the human FKBP59. Because of the high similarity in sequence to wFKBP73, wFKBP77 was designated as the heat-induced isoform. The wFKBP77 mRNA steady-state level was 14-fold higher at 37°C than at 25°C. The wFKBP77 transcript abundance was the highest in mature embryos that had imbibed and 2-d-old green shoots exposed to 37°C, and decreased to 6% in 6-d-old green shoots. The transcript level returned to the level detected at 25°C after recovery of the embryos for 90 min at 25°C. We compared wFKBP73 and wFKBP77 with the heat-shock proteins having cognate and heat-stress-induced counterparts.

Differential synaptic localization of two major gamma-aminobutyric acid type A receptor alpha subunits on hippocampal pyramidal cells.

Hippocampal pyramidal cells, receiving domain specific GABAergic inputs, express up to 10 different subunits of the gamma-aminobutyric acid type A (GABAA) receptor, but only 3 different subunits are needed to form a functional pentameric channel. We have tested the hypothesis that some subunits are selectively located at subsets of GABAergic synapses. The alpha 1 subunit has been found in most GABAergic synapses on all postsynaptic domains of pyramidal cells. In contrast, the alpha 2 subunit was located only in a subset of synapses on the somata and dendrites, but in most synapses on axon initial segments innervated by axo-axonic cells. The results demonstrate that molecular specialization in the composition of postsynaptic GABAA receptor subunits parallels GABAergic cell specialization in targeting synapses to a specific domain of postsynaptic cortical neurons.

Spatial organization of retinal information about the direction of image motion.

The visual stimuli that elicit neural activity differ for different retinal ganglion cells and these cells have been categorized by the visual information that they transmit. If specific visual information is conveyed exclusively or primarily by a particular set of ganglion cells, one might expect the cells to be organized spatially so that their sampling of information from the visual field is complete but not redundant. In other words, the laterally spreading dendrites of the ganglion cells should completely cover the retinal plane without gaps or significant overlap. The first evidence for this sort of arrangement, which has been called a tiling or tessellation, was for the two types of "alpha" ganglion cells in cat retina. Other reports of tiling by ganglion cells have been made subsequently. We have found evidence of a particularly rigorous tiling for the four types of ganglion cells in rabbit retina that convey information about the direction of retinal image motion (the ON-OFF direction-selective cells). Although individual cells in the four groups are morphologically indistinguishable, they are organized as four overlaid tilings, each tiling consisting of like-type cells that respond preferentially to a particular direction of retinal image motion. These observations lend support to the hypothesis that tiling is a general feature of the organization of information outflow from the retina and clearly implicate mechanisms for recognition of like-type cells and establishment of mutually acceptable territories during retinal development.

An Empirical Comparison of Reuse in Embedded and Nonembedded Systems

High-quality software, delivered on time and budget, constitutes a critical part of most products and services in modern society. Our government has invested billions of dollars to develop software assets, often to redevelop the same capability many times. Recognizing the waste involved in redeveloping these assets, in 1992 the Department of Defense issued the Software Reuse Initiative. The vision of the Software Reuse Initiative was "To drive the DoD software community from its current "re-invent the software" cycle to a process-driven, domain-specific, architecture-centric, library-based way of constructing software.'' Twenty years after issuing this initiative, there is evidence of this vision beginning to be realized in nonembedded systems. However, virtually every large embedded system undertaken has incurred large cost and schedule overruns. Investigations into the root cause of these overruns implicates reuse. Why are we seeing improvements in the outcomes of these large scale nonembedded systems and worse outcomes in embedded systems? This question is the foundation for this research. The experiences of the Aerospace industry have led to a number of questions about reuse and how the industry is employing reuse in embedded systems. For example, does reuse in embedded systems yield the same outcomes as in nonembedded systems? Are the outcomes positive? If the outcomes are different, it may indicate that embedded systems should not use data from nonembedded systems for estimation. Are embedded systems using the same development approaches as nonembedded systems? Does the development approach make a difference? If embedded systems develop software differently from nonembedded systems, it may mean that the same processes do not apply to both types of systems. What about the reuse of different artifacts? Perhaps there are certain artifacts that, when reused, contribute more or are more difficult to use in embedded systems. Finally, what are the success factors and obstacles to reuse? Are they the same in embedded systems as in nonembedded systems? The research in this dissertation is comprised of a series of empirical studies using professionals in the aerospace and defense industry as its subjects. The main focus has been to investigate the reuse practices of embedded systems professionals and nonembedded systems professionals and compare the methods and artifacts used against the outcomes. The research has followed a combined qualitative and quantitative design approach. The qualitative data were collected by surveying software and systems engineers, interviewing senior developers, and reading numerous documents and other studies. Quantitative data were derived from converting survey and interview respondents' answers into coding that could be counted and measured. From the search of existing empirical literature, we learned that reuse in embedded systems are in fact significantly different from nonembedded systems, particularly in effort in model based development approach and quality where the development approach was not specified. The questionnaire showed differences in the development approach used in embedded projects from nonembedded projects, in particular, embedded systems were significantly more likely to use a heritage/legacy development approach. There was also a difference in the artifacts used, with embedded systems more likely to reuse hardware, test products, and test clusters. Nearly all the projects reported using code, but the questionnaire showed that the reuse of code brought mixed results. One of the differences expressed by the respondents to the questionnaire was the difficulty in reuse of code for embedded systems when the platform changed. The semistructured interviews were performed to tell us why the phenomena in the review of literature and the questionnaire were observed. We asked respected industry professionals, such as senior fellows, fellows and distinguished members of technical staff, about their experiences with reuse. We learned that many embedded systems used heritage/legacy development approaches because their systems had been around for many years, before models and modeling tools became available. We learned that reuse of code is beneficial primarily when the code does not require modification, but, especially in embedded systems, once it has to be changed, reuse of code yields few benefits. Finally, while platform independence is a goal for many in nonembedded systems, it is certainly not a goal for the embedded systems professionals and in many cases it is a detriment. However, both embedded and nonembedded systems professionals endorsed the idea of platform standardization. Finally, we conclude that while reuse in embedded systems and nonembedded systems is different today, they are converging. As heritage embedded systems are phased out, models become more robust and platforms are standardized, reuse in embedded systems will become more like nonembedded systems.

El lenguaje gráfico de Eduardo Chillida como aportación conceptual para la identidad tipográfica de la Universidad del País Vasco —UPV/EHU—

Este proyecto de investigación financiado por la Universidad del País Vasco/Euskal Herriko Unibertsitatea —UPV/EHU-PES 11/31—, a través de su programa de investigación estratégica, tiene como objetivo la creación de la tipografía de identidad visual corporativa de la Universidad del País Vasco —UPV/EHU—, cuyo inicio conceptual para dotar de unas características de identidad visual corporativa a la UPV/EHU, ha sido planteado desde las especulaciones estéticas sobre la forma, materializadas por Eduardo Chillida. En la producción gráfica de este artista encontramos una sutil coincidencia con principios vitales para la creación tipográfica, en cuanto al planteamiento de formas dinámicas y constructivas, en las que el rigor geométrico es vencido por una suerte de organicidad que parte del núcleo mismo de la estructura —«cursus»—, por: la fuerza vital que imprime la acción modulada del gesto —«ductus»—; por la dialéctica entre lo lleno y lo vacío —forma/contraforma—, por el impulso y la espontaneidad — carácter—, o por la afirmación de un lenguaje plástico en la cultura diferenciada del medio en el que se vive —identidad—.

Transfer of Pattern Recall Skills May Contribute to the Development of Sport Expertise

Superior recall of domain-specific patterns is well established as a defining attribute of expert performers. Recent studies on the developmental histories of expert team ball sport players (e.g. Baker, Côté, & Abernethy, 2003a) also suggest that experts characteristically receive exposure to a wide range of sports in their developing years and that this related sports experience may reduce the amount of sport-specific training needed to become an expert. This study examined whether the facilitation of expertise associated with other sport experience might arise from positive transfer of pattern recall skills from one sport to another. Expert netball, basketball and field hockey players and experienced non-experts performed a recall task for patterns of play derived from each of these sports. Experts from sports different to those shown in the presented pattern consistently outperformed non-experts in their recall of defensive player positions, suggesting some selective transfer of pattern recall skills may indeed be possible

The Moldable Inspector

Object inspectors are an essential category of tools that allow developers to comprehend the run-time of object-oriented systems. Traditional object inspectors favor a generic view that focuses on the low-level details of the state of single objects. Based on 16 interviews with software developers and a follow-up survey with 62 respondents we identified a need for object inspectors that support different high-level ways to visualize and explore objects, depending on both the object and the current developer need. We propose the Moldable Inspector, a novel inspector model that enables developers to adapt the inspection workflow to suit their immediate needs by making the inspection context explicit, providing multiple interchangeable domain-specific views for each object, and supporting a workflow that groups together multiple levels of connected objects. We show that the Moldable Inspector can address multiple kinds of development needs involving a wide range of objects.