bluuebunny/crossref_metadata_2025_split huggingface dataset:
Concise Review: Workshop Review: Understanding and Assessing the Risks of Stem Cell-Based Therapies
Authors: Heslop James A. , Hammond Thomas G. , Santeramo Ilaria , Tort Piella Agnès , Hopp Isabel , Zhou Jing , Baty Roua , Graziano Enrique I. , Proto Marco Bernabé , Caron Alexis , Sköld Patrik , Andrews Peter W. , Baxter Melissa A. , Hay David C. , Hamdam Junnat , Sharpe Michaela E. , Patel Sara , Jones David R. , Reinhardt Jens , Danen Erik H.J. , Ben-David Uri , Stacey Glyn , Björquist Petter , Piner Jacqueline , Mills John , Rowe Cliff , Pellegrini Giovanni , Sethu Swaminathan , Antoine Daniel J. , Cross Michael J. , Murray Patricia , Williams Dominic P. , Kitteringham Neil R. , Goldring Chris E.P. , Park B. Kevin 
Published: February 2015

Abstract
The field of stem cell therapeutics is moving ever closer to widespread application in the clinic. However, despite the undoubted potential held by these therapies, the balance between risk and benefit remains difficult to predict. As in any new field, a lack of previous application in man and gaps in the underlying science mean that regulators and investigators continue to look for a balance between minimizing potential risk and ensuring therapies are not needlessly kept from patients. Here, we attempt to identify the important safety issues, assessing the current advances in scientific knowledge and how they may translate to clinical therapeutic strategies in the identification and management of these risks. We also investigate the tools and techniques currently available to researchers during preclinical and clinical development of stem cell products, their utility and limitations, and how these tools may be strategically used in the development of these therapies. We conclude that ensuring safety through cutting-edge science and robust assays, coupled with regular and open discussions between regulators and academic/industrial investigators, is likely to prove the most fruitful route to ensuring the safest possible development of new products.
Systemically Delivered Adipose Stromal Vascular Fraction Cells Disseminate to Peripheral Artery Walls and Reduce Vasomotor Tone Through a CD11b+ Cell-Dependent Mechanism
Authors: Morris Marvin E. , Beare Jason E. , Reed Robert M. , Dale Jacob R. , LeBlanc Amanda J. , Kaufman Christina L. , Zheng Huaiyu , Ng Chin K. , Williams Stuart K. , Hoying James B. 
Published: February 2015

Abstract
Vasoactivity, an important aspect of tissue healing, is often compromised in disease and tissue injury. Dysfunction in the smaller vasoactive arteries is most impactful, given the role of these vessels in controlling downstream tissue perfusion. The adipose stromal vascular fraction (SVF) is a mix of homeostatic cells shown to promote tissue healing. Our objective was to test the hypothesis that autologous SVF cells therapeutically modulate peripheral artery vasoactivity in syngeneic mouse models of small artery function. Analysis of vasoactivity of saphenous arteries isolated from normal mice 1 week after intravenous injection of freshly isolated SVF cells revealed that pressure-dependent artery vasomotor tone was decreased by the SVF cell isolate, but not one depleted of CD11b+ cells. Scavenging hydrogen peroxide in the vessel wall abrogated the artery relaxation promoted by the SVF cell isolate. Consistent with a CD11b+ cell being the relevant cell type, SVF-derived F4/80-positive macrophages were present within the adventitia of the artery wall coincident with vasorelaxation. In a model of artery inflammation mimicking a common disease condition inducing vasoactive dysfunction, the SVF cells potentiated relaxation of saphenous arteries without structurally remodeling the artery via a CD11b+ cell-dependent manner. Our findings demonstrate that freshly isolated, adipose SVF cells promote vasomotor relaxation in vasoactive arteries via a hydrogen peroxide-dependent mechanism that required CD11b+ cells (most likely macrophages). Given the significant impact of small artery dysfunction in disease, we predict that the intravenous delivery of this therapeutic cell preparation would significantly improve tissue perfusion, particularly in diseases with diffuse vascular involvement.
L’art et le féminisme au Québec
Authors: Beaudry Lucille 
Published: February 2015

Le féminisme en art au Québec s’est démarqué à partir du contexte d’agitation sociale et politique des années 60 et 70. Cet art s’est implanté notamment en illustrant une trajectoire concernant le sujet de l’identité femme. Celle-ci va d’une position dite essentialiste du sujet femme à une illustration de la construction sociale de l’identité de genre, identité dont la déconstruction renvoie à la pluralisation de l’identité dans le temps et dans l’espace. Ces oeuvres contribuent de diverses manières, à partir de l’irréductibilité des différences, à la réflexion portant sur une démocratie plurielle et radicale.
La post-pornographie comme art féministe
Authors: Lavigne Julie 
Published: February 2015

Dans un contexte de pluralisation des stratégies féministes, le développement d’une pornographie féministe, queer, ou encore ce que les Européennes ou Annie Sprinkle appellent la « post-pornographie », peut-il être envisagé comme un projet féministe viable ou même souhaitable? L’auteure présente une analyse de cette création de pornographie critique et féministe, à la lumière du concept de post-pornographie, dans le champ des arts visuels, plus particulièrement des images en mouvements. Elle trace une généalogie de cette pratique à partir de trois oeuvres réalisées à trois moments clés de cette production : le film expérimental Fuses (1965), de Carolee Schneemann, la vidéo Sluts and Goddesses Video Workshop or How to Be a Sex Goddess in 101 Easy Steps (1992), d’Annie Sprinkle, et le film Too much Pussy. Feminist Sluts in Queer X Show (2010), d’Émilie Jouvet.
Bayesian Belief Networks (BBNs)
Authors: Fenton Norman 
Published: February 2015

AbstractBayesian belief networks (also known asbelief networks,causal probabilistic networks,causal nets,graphical probability networks,probabilistic cause–effect models, andprobabilistic influence diagrams) provide decision‐support for a wide range of problems involving uncertainty and probabilistic reasoning. The underlying theory of BBNs is Bayesian probability theory and the notion of propagation. Although this has been around for a long time it is only since the late 1980s that efficient algorithms and tools to implement them have been developed to enable propagation in networks with a reasonable number of variables. The recent explosion of interest in BBNs is due to these developments, which mean that for the first time realistic size problems can be solved. These developments make BBNs an excellent method for reasoning about uncertainty. BBNs have proved useful in applications such as medical diagnosis and diagnosis of mechanical failures. Within the software engineering community the interest in BBNs is motivated by the need to integrate diverse types of evidence to provide rigorous quantitative dependability/safety arguments. BBNs enable us to incorporate not just the results from testing but also other evidence about the process and product; this evidence can be both objective and subjective. The BBN forces the assessor to expose all assumptions about the impact of different forms of evidence and hence provides a visible and auditable dependability or safety argument. This article provides a very brief introduction to BBNs and explains how they can be used for assessing critical systems.
Black‐Box Testing
Authors: Ostrand Thomas 
Published: February 2015

Abstract

Black‐box testing
of software is any method of generating testcases that is independent of the software's internal structure. Since black‐box testing is always based, either directly or indirectly, on the software's specification, it is also called
specification‐based testing
. The simplest concept of black‐box testing is that the tester examines the program's specification and chooses test cases that exercise all its externally visible functions. In selecting these black‐box tests, the tester considers the program's purpose, the sets of possible inputs and expected outputs, possible ways in which the program might fail, and possible uses of the program. The art of testing consists of approaching each of these sources of tests in an organized way, and in using whichever sources are most appropriate for the particular software and its intended use. Various specific types of black‐box testing are
model‐based testing
,
scenario‐based testing
,
data‐based testing
,
statistical testing
, and (a special case of the latter two approaches)
random testing
, all of these types are discussed. Other terms sometimes used as synonyms for black‐box testing are
functional testing
and
behavioral testing
. The rationale for these usages is that black‐box tests are based on the
function
or
behavior
to be performed by the software, not its structure or design. However, because of the multiple meanings possible for
function
, these terms are potentially misleading.
Cold
Authors: Jonkers Hans B. M. 
Published: February 2015

AbstractThe name Common Object‐oriented Language for Design (COLD) stands for a family of languages developed by Philips Research Laboratories Eindhoven, with the main aim of makingformal techniquesuseful in the context of industrial software development. The development of these languages is based on the conviction that the systematic development of industrial software requires anintegrated approach, not only at the methodological but also at the language level. The COLD languages therefore constitute what is sometimes called awide‐spectrum language: an integrated linguistic framework supporting descriptive techniques relevant to the various stages of software development (ranging from specification to implementation). In this sense, COLD can be viewed as a single language unifying the features of a specification, design and programming language.
Software Configuration Management Tools
Authors: Ventimiglia Bob 
Published: February 2015

Abstract

Most tools sold under the SCM banner of are point solutions, which do not address all the aspects of the SCM discipline or its operational execution. In other words, they do not address the four major elements identified in the IEEE definition of CM:
identification
,
change management
,
status accounting
, and
audit
. They also do not address SCM as “a management tool that applies an engineering discipline to manage the evolution of a software system from concept through to system retirement. The primary focus of this discipline is to ensure the repeatability, traceability, and integrity of the system being developed and produced.” As a result, it is incumbent on the evaluator/selector and user of SCM tools to understand what their requirements are, what business problems they are trying to resolve, and what functionality is really needed to effectively satisfy those requirements.

Establishing tool requirements is the most important step in selecting and implementing SCM tools. The requirements definition process frequently includes requirements that should not be heavily weighted, yet are standard definitions of CM focus more on the goals of CM, such as maintaining integrity of data and verifying the consistency of configurations. When buying a CM tool, it is the operational aspects of CM (version and workspace management, etc., described here) that provide functionality over the complete evolution of a product from concept to retirement that are important to consider.
One way to classify SCM tools is by the underlying computing architecture, such as client/server, mainframe, or distributed. Another approach is to examine the operations or functions that tools execute. Using a functional approach simplifies comparison of different tools and determining which one best satisfies the requirements that have been defined. A third approach combines goal‐based definitions of SCM with the functions that address them, and is described.
Coupling
Authors: Heyliger George E. 
Published: February 2015

AbstractDealing with complexity is a major issue of modern software system design. Complexity has been variously shown to be correlated with development cost, testing difficulty, residual errors, and maintenance effort. Coupling among distinct system elements has long been regarded as a major contributor to system complexity. Cohesion, or strength, characterizes the couplinginternalto a subsystem, as distinct from the couplingamongsubsystems. Cohesion is a desirable quality because of the localization of the behavioral attributes of a subsystem. Understanding of a cohesive subsystem can be largely confined to understanding the subsystems themselves. Localized development and maintenance activities can be performed with greater confidence and with lower expenditure of resources.Useful subsystems must interact, i.e., be coupled, with other subsystems in the larger context. Limiting these interactions facilitates understanding of system behavior, because most aspects of interest are then largely confined to a single subsystem. Evidently, exploring systemwide coupling and cohesion provides an overall assessment of design desirability or quality. Aquantitativeassessment of coupling not only provides an objective evaluation criteria but also can help focus attention on those aspects of a design for which additional effort will improve a systemwide score.Meyer and Yourdon and Constantine describe several classes of coupling, both internal and external. These attributes are intended as qualitative design guidelines in the pairwise assessment of module properties. These article offers a relative weighting for the several types of coupling. Recent work provides an approach to quantitative measures of coupling and cohesion based on observing structural and syntactic properaties of Ada source code. The above classes of coupling suggest useful viewpoints of system design. The approach described here depends only on some linkage among objects (for which linkage and object can be abstractions at the conceptual level) or attributes such as source code syntax at the detailed design level. Thus, unlike the other referenced work, the following approach supports design analysis at any phase of the development.
Data Flow Testing
Authors: Weyuker Elaine J. 
Published: February 2015

AbstractData flow testing is a family of white‐box testing techniques, relying on information deriving from both the flow of control and the flow of data through the program. Most other white‐box testing strategies rely only on the program's flow of control. A second distinction between this family of testing strategies and other white‐box strategies is that data flow strategies assure that different parts of the code that are related by the flow of data are tested together by requiring that test cases be chosen that exercise these related parts together. In contrast to this, most other white‐box strategies, such as statement testing or branch testing, require only that every identified program element be exercised at some point, but not necessarily in combination with other specified program elements. This means that certain meaningful code interactions may go uninspected and hence certain classes of faults may be overlooked even though the code containing these faults is exercised during testing.The data flow criteria are based on analysis that is similar to that done by an optimizing compiler, classifying occurrences of variables in a program as being either definitions or uses. Programs will be represented byflow graphs, consisting of nodes that representblocksor sequences of statements that are always exercised as a unit, and edges that represent the flow of control between blocks. A number of tools have been implemented to assess the degree to which a set of test cases satisfy one of the data flow criteria for a given program. Various definitions of a family of data flow testing criteria are given.
Data Rights
Authors: Watt‐Morse Peter M. 
Published: February 2015

AbstractJust as a programmer applies software engineering concepts to create high quality computer code, a software owner must “engineer” data rights to create optimum legal protections for such code. To engineer data rights, a software owner must (1) evaluate the software's intended uses and users, (2) select the appropriate data rights considering the inherent advantages and constraints of the available legal “tools” (e.g., copyrights, trade secrets, patents, or trademarks), and (3) take the necessary steps to develop the selected data rights. If engineered correctly, the resulting data rights will effectively use available legal tools, be fully compatible with the software's intended uses, and provide the owner with practical legal safeguards to protect the economic value of the software.This article is intended to introduce software engineers to data rights available in the United States and the considerations in choosing the appropriate data rights. Although a treatise on intellectual property law is beyond the scope of an introductory chapter, a clear understanding of the basic legal rules for each type of data right is essential. Therefore, this chapter reviews the legal framework for the following data rights: copyrights, trade secrets, patents, trademarks, and mask works. With this framework in place, the chapter examines the considerations in selecting particular data rights. Finally, the chapter highlights data‐right issues that software engineers encounter on a regular basis (e.g., extent of copyright protection, employee ownership, governmental data rights, and Internet issues).
Database Engineering
Authors: Wiederhold Gio , Qian Xiaolei 
Published: February 2015

AbstractThe data‐oriented approach to the design of data‐processing programs provides a promising alternative to the traditional design of software. The termdata engineeringor (database engineering) is used to describe this methodology and pose it as an alternative tosoftware engineering. A number of software engineering techniques remain valid, but the methodological setting is drastically different.Data engineering focuses on the data. Of prime concern in data engineering are the proper representation and communication of data, so that many processes can share the information contained in the data. This design methodology then depends on an analysis of the meaning and structure of the data. The data engineering approach is appropriate whenDatapersistlonger than programs; andMany programssharethe same data.In data processing, and especially in transaction‐oriented systems, these conditions predominate.In data engineering the primitives and relationships among them are structured objects. In contrast to object‐oriented programming, data engineering does not endow the objects with extensive procedural capability, since procedural information is difficult to share, especially in large systems using diverse languages. Instead, one must attempt to represent the semantics structurally, by identifying the structure types that are being used. Behavior is associate with these types. For processing the applications interpret the semantics with the typed objects. The concern is not the actual representation; two objects could have identical representation, but be typed distinctly.Relationships connect the objects. Many processing rules are best derived from constraints associated with connections. Again, one must structurally identify the connection types and permit them to be interpreted.
Database Management Systems in Engineering
Authors: Morris K. C. , Mitchell Mary , Dabrowski Christopher , Fong Elizabeth 
Published: February 2015

AbstractMost engineering‐related software addresses specific problems. These problems are typically computation‐intensive and limited in scope. Until relatively recently this approach has been an effective use of computer and human resources. However, in the future, engineering and manufacturing processes will need more integrated product development environments. Both cultural and procedural changes are needed to support the engineering environments of the future, and these changes will require integrated software systems. Databases are essential for integrating software and for reliably sharing data among diverse groups of people and applications. Database technology will be an integral part of the emerging software environments.In this article the application of database technology to engineering problems is examined for different levels of complexity within the computing environment. This introduction provides some background on the topic and includes the description of an example that is used throughout the article. In the first section, the use of database technology for standalone applications is considered. Mechanisms for data representation to support engineering applications are particularly important for implementing engineering software. The second section discusses database techniques for managing changes within the software environment. The third section discusses considerations for supporting multiple engineers working cooperatively. The state of database technology is discussed in the concluding section.
Debugging in Distributed Systems
Authors: Leblanc Thomas J. 
Published: February 2015

AbstractDebugging sequential programs on a uniprocessor is a fairly well‐understood task. A good interactive debugger supports breakpoints and single‐step execution for a line‐by‐line analysis of the effect of procedures and instructions on program state, all in the context of the original source code. At any moment in time, the user can halt execution and examine any aspect of the program's state, tracing the relationship between source code and error symptoms at whatever level of detail desired.Distributed systems, on the other hand, introduce enormous complications for debugging. The physical separation of processors and the communication delays between processors make halting all processors instantaneously impossible. There are properties that adds a dimension to the problem of debugging that is not present with sequential programs.Perhaps the greatest difficulty stems from the uncertainty present in any system with unpredictable communication delays. Any debugging technique that requires use of the processors or communication medium can introduce these delays, and obscure the true execution being observed.Distributed systems require debugging techniques that explicitly address the uncertainty inherent in distributed systems. Not all queries are possible, especially queries that require the debugger to know something about the state of two different processors at the same precise moment in time. In fact, distributed systems require a new notion of time, where time is relative to the processor making the observation. In addition, since a distributed program is made up of many sequential programs, distributed systems need an expanded notion of program state and the events that cause changes in that state. Distributed systems also need new techniques for monitoring program executions and new debugging tools that allow for examination of the execution state and interact with a program in execution.In a distributed system, processes communicate by exchanging messages. Therefore, message operations are the primary events of interest during debugging. There are several techniques that can be used to monitor execution and recognize the occurrence of message events.During the debugging cycle, the debugger and user interact to find the source of errors. The debugger captures execution information and presents it to the user; the user analyzes the information, makes hypotheses, initiates experiments, and requests more information. Thus, the way in which the debugger presents information to the user is crucial. As with any software system, there are a variety of ways to present information to the user.Despite the many advances made since 1985 or so, distributed program debugging remains a difficult problem. Problems (among others) will be the focus of research efforts, while users continue to gain valuable experience with the techniques already developed.