Background LINCS, “Library of Integrated Network-based Cellular Signatures”, and IDG, “Illuminating the Druggable Genome”, are both NIH projects and consortia that have generated rich datasets for the study of the molecular basis of human health and disease. LINCS L1000 expression signatures provide unbiased systems/omics experimental evidence. IDG provides compiled and curated knowledge for illumination and prioritization of novel drug target hypotheses. Together, these resources can support a powerful new approach to identifying novel drug targets for complex diseases, such as Parkinson’s disease (PD), which continues to inflict severe harm on human health, and resist traditional research approaches. Results Integrating LINCS and IDG, we built the Knowledge Graph Analytics Platform (KGAP) to support an important use case: identification and prioritization of drug target hypotheses for associated diseases. The KGAP approach includes strong semantics interpretable by domain scientists and a robust, high performance implementation of a graph database and related analytical methods. Illustrating the value of our approach, we investigated results from queries relevant to PD. Approved PD drug indications from IDG’s resource DrugCentral were used as starting points for evidence paths exploring chemogenomic space via LINCS expression signatures for associated genes, evaluated as target hypotheses by integration with IDG. The KG-analytic scoring function was validated against a gold standard dataset of genes associated with PD as elucidated, published mechanism-of-action drug targets, also from DrugCentral. IDG’s resource TIN-X was used to rank and filter KGAP results for novel PD targets, and one, SYNGR3 (Synaptogyrin-3), was manually investigated further as a case study and plausible new drug target for PD. Conclusions The synergy of LINCS and IDG, via KG methods, empowers graph analytics methods for the investigation of the molecular basis of complex diseases, and specifically for identification and prioritization of novel drug targets. The KGAP approach enables downstream applications via integration with resources similarly aligned with modern KG methodology. The generality of the approach indicates that KGAP is applicable to many disease areas, in addition to PD, the focus of this paper.

Representation learning provides new and powerful graph analytical approaches and tools for the highly valued data science challenge of mining knowledge graphs. Since previous graph analytical methods have mostly focused on homogeneous graphs, an important current challenge is extending this methodology for richly heterogeneous graphs and knowledge domains. The biomedical sciences are such a domain, reflecting the complexity of biology, with entities such as genes, proteins, drugs, diseases, and phenotypes, and relationships such as gene co-expression, biochemical regulation, and biomolecular inhibition or activation. Therefore, the semantics of edges and nodes are critical for representation learning and knowledge discovery in real world biomedical problems. In this paper, we propose the edge2vec model, which represents graphs considering edge semantics. An edge-type transition matrix is trained by an Expectation-Maximization approach, and a stochastic gradient descent model is employed to learn node embedding on a heterogeneous graph via the trained transition matrix. edge2vec is validated on three biomedical domain tasks: biomedical entity classification, compound-gene bioactivity prediction, and biomedical information retrieval. Results show that by considering edge-types into node embedding learning in heterogeneous graphs, edge2vec significantly outperforms state-of-the-art models on all three tasks. We propose this method for its added value relative to existing graph analytical methodology, and in the real world context of biomedical knowledge discovery applicability.

Contestants will have the opportunities to submit a written summary of their technical innovations, to a panel of experts before the OOPSLA Idol Event (Panel). The experts (judges) will cull through the submissions and the top 5 will be asked to present their ideas to the judges. The judges will comment on the ideas and the audience will vote for the best submission.

There is a huge amount of Fortran code that is too valuable to throw away, but very expensive to maintain. Refactoring tools have had a great impact on the productivity of object-oriented developers and the quality of code. However, high- performance languages such as C and Fortran do not have these tools. Moreover, refactorings specific to high-performance and parallel computing have not yet been adequately examined. This paper describes Photran, an integrated development environment for Fortran that will support automated refactoring and how a tool like this can be used to reduce the cost of maintenance and development of systems implemented in Fortran.

OOPSLA attendees have traditionally looked to the panel program for red-meat relief from a diet of high-fiber technical track material and abstruse Onward! exotica. However, panels often feature a tired parade of the usual suspects: the same faces hawking the same hackneyed twentieth century ideas over and over again. At the same time, familiar names are a predicable draw. The effect is that it may take many years for new blood to find its way into the panel program.This panel seeks to break this logjam by featuring only panelists at or under the age of 0x20. They will offer their opinions and insights as to what we have been doing wrong for the last twenty years and what they will have to do fix it. Grudging recognition of what has gone right may be offered as well.Mechanisms to guarantee the anonymity of the most brash positions will allow the participants to be provocative as well as precocious.

Wrappers are mechanisms for introducing new behavior that is executed before and/or after, and perhaps even in lieu of, an existing method. This paper examines several ways to implement wrappers in Smalltalk, and compares their performance. Smalltalk programmers often use Smalltalk's lookup failure mechanism to customize method lookup. Our focus is different. Rather than changing the method lookup process, we modify the method objects that the lookup process returns. We call these objects method wrappers. We have used method wrappers to construct several program analysis tools: a coverage tool, a class collaboration tool, and an interaction diagramming tool. We also show how we used method wrappers to construct several extensions to Smalltalk: synchronized methods, assertions, and multimethods. Wrappers are relatively easy to build in Smalltalk because it was designed with reflective facilities that allow programmers to intervene in the lookup process. Other languages differ in the degree to which they can accommodate change. Our experience testifies to the value, power, and utility of openness.

There is a huge amount of Fortran code that is too valuable to throw away, but very expensive to maintain. Refactoring tools have had a great impact on the productivity of object-oriented developers and the quality of code. However, highperformance languages such as C and Fortran do not have these tools. Moreover, refactorings specific to high-performance and parallel computing have not yet been adequately examined. This paper describes Photran, an integrated development environment for Fortran that will support automated refactoring and how a tool like this can be used to reduce the cost of maintenance and development of systems implemented in Fortran.

Smalltalk-80 is a pure object-oriented language in which messages are dispatched according to the class of the receiver, or first argument, of a message. Object-oriented languages that support multimethods dispatch messages using all their arguments. While Smalltalk does not support multimethods, Smalltalk's reflective facilities allow programmers to efficiently add them to the language. This paper explores several ways in which this can be done, and the relative efficiency of each. Moreover, this paper can be seen as a lens through which the design issues raised by multimethods, as well as by using metaobjects to build them, can be more closely examined.

Article Share on Breakthrough ideas Authors: James O. Coplien DAFCA DAFCAView Profile , Brian Foote University of Illinois University of IllinoisView Profile , Richard P. Gabriel Sun Labs Sun LabsView Profile , Dave Thomas Bedarra BedarraView Profile , Cristina Lopes UC Irvine UC IrvineView Profile , Brian Marick Testing Foundations Testing FoundationsView Profile , Bonnie Nardi UC Irvine UC IrvineView Profile , Rob Tow Sun Labs Sun LabsView Profile , Andrew Hunt The Pragmatic Programmers The Pragmatic ProgrammersView Profile , Glenn Vanderburg Countrywide Home Loans Countrywide Home LoansView Profile Authors Info & Claims OOPSLA '05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applicationsOctober 2005Pages 76–86https://doi.org/10.1145/1094855.1094863Published:16 October 2005Publication History 1citation551DownloadsMetricsTotal Citations1Total Downloads551Last 12 Months1Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Not since the advent of the integrated development environment has a development tool had the impact on programmer productivity that refactoring tools have had for object-oriented developers. However, at the present time, such tools do not exist for high-performance languages such as C and Fortran; moreover, refactorings specific to high-performance and parallel computing have not yet been adequately examined. We observe that many common refactorings for object-oriented systems have clear analogs in procedural Fortran. The Fortran language itself and the introduction of object orientation in Fortran 2003 give rise to several additional refactorings. Moreover, we conjecture that many hand optimizations common in supercomputer programming can be automated by a refactoring engine but deferred until build time in order to preserve the maintainability of the original code base. Finally, we introduce Photran, an integrated development environment that will be used to implement these transformations, and discuss the impact of such a tool on legacy code reengineering.This work is being funded by IBM under the PERCS project.

From the Publisher:Design patterns have moved into the mainstream of commercial software development as a highly effective means of improving the efficiency and quality of software engineering, system design, and development. Patterns capture many of the best practices of software design, making them available to all software engineers.. "This book covers a wide range of topics, with patterns in the areas of object-oriented infrastructure, programming strategies, temporal patterns, security, domain-oriented patterns, human-computer interaction, reviewing, and software management.

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines the most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. In order to become so popular, it must be doing something right. If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

This paper examines a set of three patterns that examine the issues that arise when data are to be shared among several applications in one or more different formats. When an ENGLISH ONLY/STANDARD REPRESENTATION can be used, conversion and translation are moot issues. However, this simplicity is not without its cost. When freely CONVERTIBLE CURRENCIES are available, data are not isolated and trapped by incompatible representations. However, as the number of formats increases, conversion becomes a complicated problem. A LINGUA FRANCA addresses the problem posed when representations proliferate. If a standard secondary tongue is adopted, a much smaller number of translators or converters is required to ensure universal translation.

This paper examines a set of three patterns that examine the issues that arise when data are to be shared among several applications in one or more different formats. When an ENGLISH ONLY/STANDARD REPRESENTATION can be used, conversion and translation are moot issues. However, this simplicity is not without its cost. When freely CONVERTIBLE CURRENCIES are available, data are not isolated and trapped by incompatible representations. However, as the number of formats increases, conversion becomes a complicated problem. A LINGUA FRANCA addresses the problem posed when representations proliferate. If a standard secondary tongue is adopted, a much smaller number of translators or converters is required to ensure universal translation.

classes and frameworks should be bundled with at least one fully functional set of working, concrete subclasses or components (in other words, a working example). Such example objects, classes, and frameworks should come with fully functional, working test programs, and these programs should be accompanied by sample input and output objects or files, where relevant. It’s almost always not enough to merely document an artifact’s interface. Providing working examples of how interfaces are actually used helps to resolve ambiguity and uncertainty and fosters confidence. Instructions that describe how run these examples should be included too. These minimal working examples are particularly important when the user is called upon to master complex interfaces. Users should not be left sitting frustrated on Christmas Day because the batteries were not included. One way to learn how a new artifact works is to methodically study its code and documentation. Another is to dive in cold and experiment with the artifact, and thereby get a sense of what it can do. Initial success with such experiments will give programmers the confidence they need to delve more deeply into these object. Working examples can serve as test beds for exploratory experimentation. Such exploration can permit programmers to incrementally learn how to use an artifact, while keeping the growing example working. Programmers can progress from tinkering with this working examples to verify that they can rebuild them correctly, to a point where they feel that their command of the interface of the objects they are using is sufficient to justify embedding these objects in their own applications. At the beginning of this process, when every aspect of such a program will be new, and probably opaque to the programmer, it is particularly important that getting the artifact to work be as painless as possible. Programs should exhibit reasonable behavior in the absence of arguments or pre-existing data. Therefore, design objects so that they will exhibit reasonable behavior with default arguments. Provide everything a programmer needs to try out these objects. Make it as easy as possible for designers to see a working example. The Selfish Class Page 8 of 19 http://www.laputan.org/selfish/selfish.html 8/27/01 Designers should strive to ensure that a user's first encounter with their creations does not require elaborate preparation. You should strive to make installation effortless, and minimize user configurations. A user will never be so ignorant of the ramifications of configuration decisions as upon the first time he or she confronts a new application. Hence, programs delivered in source form should build in response to make, or something like it. Installation programs should provide a default configuration button, and allow customization later on. A design, and the objects that embody it, survive and evolve only if they are used. To be reused, they must attract programmers. To do this, they must make a good first impression. Like peacock feathers, an initial, painless presentation of impressive functionality can enhance an object's appeal. Objects which do this can flourish, and those which cannot, even if they are technically superior in other ways, may not. The following box gives several examples of things that don’t work out-of-the-box, and of things that do: