| Online Publication | Research | Reports | Top level index |
Technical Reports, Deliverables etc
 |
How to Improve the Presence of Secondary Colors in Huebars used for Heat Diagrams ? February 2009 - Werner Van Belle When working with hue-bars or heat diagrams one relies on the fact that these colors are perceived linearly and thus properly represent the underlying data. This assumption is often wrong because the secondary colors yellow and turquoise tend to use less space than the primary colors red, green and blue. In this document we design a huebar which is perceived linearly, or stated differently in which each of the colors is equally abundant: red, yellow, green, turquoise, blue, purple and red. |
 |
(Ortholog) Mapping the Applied Biosystems Human/Mouse Survey v2.0 Micro-arrays to Ensembl Gene Identifiers May 2007 - Werner Van Belle This document describes cross joining of gene tables between Celera's mouse genome identifiers, Celera human genome identifiers and the more useful Ensembl identifiers. The context in which this research is set are the genes FKRP and TAF4. By using siRNA's we interfered with the transcription and measured their effect upon the transcriptome. The Applied Biosystems 1700 micro-array scanner measured and reported the transcription quantities. Two micro-array types were used: the human genome survey v2.0 micro-arrays and the mouse genome survey v2.0 micro-arrays. Based on the different micro-array measurements we wanted to predict which proteins would be influenced in a cell system if we know the up/down regulation of the measured probes. To this end we wanted to use the human protein interaction map (as defines by Rual'06), which uses Ensembl annotated genes. This of course formed a major problem. First, the Applied Biosystems scanner does not export Ensembl gene annotations. Secondly, the human protein interaction map might not be a good model for a mouse micro-array, so we needed to go through various orthologs. This document tells two stories: first, and most annoyingly: how to get Ensembl identifiers into an Applied Biosystems micro-array. Secondly, and slightly more interesting, how to retrieve a mouse to human ortholog mapping from Ensembl. |
 |
Correlations: P53 Isoform Biosignatures vs Biomedical Parameters February 2007 - Werner Van Belle This deliverable compares 132 various biological parameters agains P53 ISoforms on 2D Gels of AML and ALL Patients. |
 |
Ship to Shore Communication August 2006 - Werner Van Belle This document describes the possible problems of developing a realtime ship to shore IP4 connection over various media such as satelite links and wifi antennas. It focuses mainly on a Linux based solution. |
 |
Stepwise Tempo Changes in BpmDj May 2006 - Werner Van Belle kbpm-play provides an algorithm that automatically changes the play-rate from its current speed back to normal speed. A first version of the software relied on a linear change of pace, which turned out to be slightly wrong. In this short article we describe what went wrong and how to do it right. |
 |
Component Oriented Design of the SEESCOA Common Test Case: The Controller and Zoom Behaviour October 2001 - Werner Van Belle This document describes the design of two components in the seescoa component system: the controller (or directory service, responsible for interconnecting most components) and the zoom behavior, responsible for providing linkage between the behaviour of two or more cameras. |
 |
Refinement of the SEESCOA Component Architecture October 2001 - Werner Van Belle This document describes the refinements we have made to the component architecture over the past 9 months. First we describe some of the esthetic things we've added to the system. These smaller refinements include the addition of a port principle. We've changed the initialisation procedure of components and other small things. In general this first section describes how one can use the component system now. The second part of this document describes some larger design enhancements, mainly to see with reification of components. This section delves a bit deeper into the component system. It discusses the why and how of the architecture. The last part describes how the component system has been made to work in a distributed context. This section also discusses why we didn't use Jini for making the component system distributed. |
June 2001 - Karsten Verelst, Werner Van Belle, Theo D'Hondt
We claim that current day reflective architectures do not offer sufficient functionality, and that new developments in computer science push us towards a stronger reflective model: reflective virtual machines. We have witnessed these shortcomings in the application domain of mobility. Strong mobility is very difficult to implement in today's programming languages, mainly because of the inability to capture the program's computational state. Therefore we propose a new reflective architecture, the reflective virtual machine, that offers sufficient support for applications in mobility. In this paper we will first describe the basic functionality a mobile agentplatform should offer. This shall be done using a solution to the malicious host problem as a case. After identifying these needs we will introduce an interpreter, the Reflective Virtual Machine, that offers sufficient reflection, so that mobile applications can be straightforwardly implemented.
 |
The SEESCOA Component System January 2001 - Werner Van Belle, David Urting Most real-time embedded systems are, by nature, multitasking solutions to real-world problems. They typically deal with the interface and control of multiple eternal devices. The different parts of these systems usually run at different priorities and with different run-time characteristcis. The notion of multiple tasks or threads being active in the system at the same time is common. Many of these real-time systems are deployed on a set of microprocessors in a distributed architecture. Designing a solution for this type of problem requires a view other than object oriented systems. This document describes the component system we developed. It describes how it should be used when programming components and it describes how the wystem itself can be adpated. The document is split in 4 parts. The first part describes what a component is and gives a good idea how to think about components (at implementation level). This part is based upon the 'Component Working Definition' deliverable. This section also contains a description of the Component System and what it is supposed to cover. The second part is a discussion about 'event based' vs 'thread based'. The third part describe how we actually can write a component. This is mainly a tutorial. The fourth part describes how we can use and tune the component system to suit our needs. |
 |
Real Time UML April 2000 - Werner Van Belle, Tom Toutenel, Viviane Jonckers This document reports on task 2.1: an extensive literature study of existing modeling techniques for real time embedded systems. These include UML-RT, UML for Embedded Systems, Octopus, ROOM and others |
April 2000 - Werner Van Belle, David Urting, Koen Debosschere, Yolande Berbers, Viviane Jonckers, Chris Luyten, Tom Toutenel
Most real-time embedded systems are, by nature, multitasking solutions to real-world problems. They typically deal with the interface and control of multiple external devices. The different parts of these systems usually run at different priorities and with different run-time characteristics. The notion of multiple tasks or threads being active in the system at the same time is common. Many of these real-time systems are deployed on a set of microprocessors in a distributed architecture. Designing a solution for this type of problem requires a new adapted view to components. This document describes the definition of a component and component system, as it will be used in the SEESCOA project. The definition is split in three parts: The first part describes what a component is and gives a good idea how to think about components. The second part describes the requirements and the responsibilities of a component system. The component system is the context in which a component has to operate. The third part looks at some additional characteristics and issues concerning components and the component system.
 |
Common Test Case April 2000 - Koen Debosschere, Theo D'Hondt, Yolande Berbers, Viviane Jonckers, Werner Van Belle, Chris Luyten, David Urting, Tom Toutenel This document reports on task 1.1: visits at the companies of the user group by the partners of the consortium. One of the objectives of this task is: Choice of one common test case that will be worked out in detail during the project. This case should be chosen to be as representative as possible, and its size should be such that it can be developed in the foreseen timeframe, integrating the results obtained during the first 2 years. The output of this activity is deliverable D1.3: description of typical applications that will be used as lighthouse and of the chosen common test case. |
April 2000 - Werner Van Belle, Tom Toutenel
Philips Belgium consists of a number of sites with different responsibilities. We listened to 5 speakers of the divisions Philips TASS, Philips ITCL, Philips Hasselt DVS (Digital Video Systems) & Philips Brugge UTV (Upmarket TV). Each speaker gave a presentation of the software development process in his division. This chapter summarizes these presentations and reflects the insight the consortium gained in Philips' development process.
| I'm currently looking for interesting work in the Basel area. If you have a challenging task with regard to data analysis and/or bioinformatics, please drop me a line. Momentan suche ich Arbeit in der Basler Umgebung. Nehmen Sie bitte kontakt auf falls Sie ein interessantes Problem im zusammenhang mit Bioinformatik und/oder Datenanalyse haben. |  |