The Research Object Suite of Ontologies: Sharing and Exchanging Research Data and Methods on the Open Web

Research in life sciences is increasingly being conducted in a digital and online environment. In particular, life scientists have been pioneers in embracing new computational tools to conduct their investigations. To support the sharing of digital objects produced during such research investigations, we have witnessed in the last few years the emergence of specialized repositories, e.g., DataVerse and FigShare. Such repositories provide users with the means to share and publish datasets that were used or generated in research investigations. While these repositories have proven their usefulness, interpreting and reusing evidence for most research results is a challenging task. Additional contextual descriptions are needed to understand how those results were generated and/or the circumstances under which they were concluded. Because of this, scientists are calling for models that go beyond the publication of datasets to systematically capture the life cycle of scientific investigations and provide a single entry point to access the information about the hypothesis investigated, the datasets used, the experiments carried out, the results of the experiments, the people involved in the research, etc. In this paper we present the Research Object (RO) suite of ontologies, which provide a structured container to encapsulate research data and methods along with essential metadata descriptions. Research Objects are portable units that enable the sharing, preservation, interpretation and reuse of research investigation results. The ontologies we present have been designed in the light of requirements that we gathered from life scientists. They have been built upon existing popular vocabularies to facilitate interoperability. Furthermore, we have developed tools to support the creation and sharing of Research Objects, thereby promoting and facilitating their adoption.Comment: 20 page

Technology-Enhanced Practice for Patients with Chronic Cardiac Disease: Home Implementation and Evaluation

Objective: This 3-year field experiment engaged 60 nurses and 282 patients in the design and evaluation of an innovative home-care nursing model, referred to as technology-enhanced practice (TEP). Methods: Nurses using TEP augmented the usual care with a web-based resource (HeartCareII) that provided patients with self-management information, self-monitoring tools, and messaging services. Results: Patients exposed to TEP demonstrated better quality of life and self-management of chronic heart disease during the first 4 weeks, and were no more likely than patients in usual care to make unplanned visits to a clinician or hospital. Both groups demonstrated the same long-term symptom management and achievements in health status. Conclusion: This project provides new evidence that the purposeful creation of patient-tailored web resources within a hospital portal is possible; that nurses have difficulty with modifying their practice routines, even with a highly-tailored web resource; and that the benefits of this intervention are more discernable in the early postdischarge stages of care

Persuading consumers to reduce their consumption of electricity in the home

Previous work has identified that providing real time feedback or interventions to consumers can persuade consumers to change behaviour and reduce domestic electricity consumption. However, little work has investigated what exactly those feedback mechanisms should be. Most past work is based on an in-home display unit, possibly complemented by lower tariffs and delayed use of non-essential home appliances such as washing machines. In this paper we focus on four methods for real time feedback on domestic energy use, developed to gauge the impact on energy consumption in homes. Their feasibility had been tested using an experimental setup of 24 households collecting minute-by-minute electricity consumption data readings over a period of 18 months. Initial results are mixed, and point to the difficulties of sustaining a reduction in energy consumption, i.e. persuading consumers to change their behaviour. Some of the methods we used exploit small group social dynamics whereby people want to conform to social norms within groups they identify with. It may be that a variety of feedback mechanisms and interventions are needed in order to sustain user interest

A model to assess customer alignment through customer experience concepts

Business and Information Technology Alignment (BITA) has been one of the main concerns of IT and Business executives and directors due to its importance to overall company performance, especially today in the age of digital transformation. For BITA has been developed several models which in general has focused in the implementation of alignment strategies for the internal operation of the organizations and in the measurement of this internal alignment, but, there is still a big gap in measurement models of the alignment with the external environment of the organizations. In this paper is presented the design and application of a maturity measurement model for BITA with the customers, where the customers are actors of the external environment of the companies. The proposed model involves evaluation criteria and business practices which the companies ideally do for improve the relationship with their customers.Comment: 12 pages, Preprint version, BIS 2019 International Workshops, Seville, Spain, June 26 to 28, 2019, Revised Paper

Variability in remote portlets

130 p.Contexto Los portales corporativos (EIP, acrónimo en inglés de Enterprise Information Portal ) integran información, personas y procesos dentro de los límites de las organizaciones. Una característica importante de los portales corporativos es la descentralización en la creación de los contenidos y la gestión de los mismos, esto ayuda a mantener la información siempre actualizada. Otra característica distintiva es que pueden atender no sólo al personal interno de la organización a la que pertenecen, sino que también son capaces de proveer servicios a personal externo tales como clientes, proveedores y socios comerciales. Los portales permiten a las personas comunicarse y colaborar, proporcionan un punto de acceso uni cado al contenido dinámico generado por las aplicaciones de negocio, fraccionan los silos de contenido y proveen información personalizada de forma e caz. Los portales son también plataformas de integración. Además de ofrecer sus propios servicios, un portal es también un conducto para aplicaciones externas. Estas aplicaciones son técnicamente conocidas como portlets. Un portlet es un componente Web con interfaz de usuario que puede ser ofrecido a través de aplicaciones de terceros (por ejemplo, un portal). Los portlets tienen interfaz de usuario, es decir, en lugar de devolver datos en crudo, los portlets presentan vistas a los usuarios. Además, los portlets son aplicaciones complejas con contexto que pueden soportar ujos de trabajos compuestos de múltiples pasos. La especi cación de portlet [6, 7] ofrece interoperabilidad entre las plataformas de portales y los portlets, estos es, permite a los desarrolladores escribir el portlet una vez, y reutilizarlo en cualquier portal que soporte la especi cación. Esto proporciona la infraestructura para hacer posible un mercado de portlets de manera que, los portales puedan ofrecer portlets provistos por terceros. En 2006 se puso en marcha el proyecto Open Source Portlet Repository Project (un repositorio de portlets de código abierto) para fomentar el libre intercambio de portlets de código abierto. Este repositorio es "una biblioteca de aplicaciones listas para correr que se pueden descargar y desplegar directamente en su portal sin, en la mayoría de los casos, con gura- 1 ciones adicionales" [2]. Otras iniciativas similares son Portlet Swap (jboss.org) y Liferay Marketplace (liferay.com). La especi cación Web Services for Remote Portlets (WSRP) va un paso más allá y permite el renderizado remoto de los portlets. El mantra de esta especi - cación es desplegar una vez, proveer en cualquier lugar . Con WSRP, un portlet puede estar alojado ( producido ) en una infraestructura completamente aislada de los portales que ofrecen ( consumen ) el portlet a sus usuarios. Esto convierte a WSRP en una solución viable para construir portales federados, es decir, una red de portales interconectados donde los recursos alojados en un portal pueden estar disponibles en muchos. Desde esta perspectiva, los portlets juegan en la capa de presentación el mismo papel que los servicios web convencionales juegan en la capa de lógica de negocio: permiten crear sistemas complejos mediante la composición de sistemas reusables más sencillos. Las principales diferencias con los servicios web tradicionales consisten en qué se está reutilizando (que incluye la interfaz de usuario) y dónde se produce la integración (en la capa de presentación). 2 Problema General La variabilidad en software es la capacidad de un sistema o artefacto software para ser modi cado, personalizado o con gurado para su uso en un contexto particular. Pero, ¿cuánta variabilidad debemos considerar? ¿Quién es consciente de la variabilidad requerida? Para responder a estas preguntas vamos a introducir un ejemplo. Considere una compañía aérea (por ejemplo, IBERIA) que ofrece dos servicios en términos de portlets: searchFlight y bookFlight. De esta manera, las agencias de viajes (por ejemplo, HALCON) pueden hacer uso de estos portlets dentro de sus portales. Los usuarios (por ejemplo, los clientes de HALCON) acceden al portal de la agencia de viajes sin ser conscientes de que searchFlight está siendo ofrecido por un tercero (es decir, IBERIA). Por lo tanto, los portlets son explícitamente desarrollados para ser utilizados en múltiples portales, ya sea desplegados localmente o provistos de forma remota. El punto importante a destacar es que los portlets pueden ser reutilizados por diversos contextos y audiencias. Por ejemplo, IBERIA ofrece sus servicios no sólo a HALCON, sino también a otras agencias de viajes (por ejemplo, EROSKI). Esto signi ca que searchFlight también debe atender a las necesidades de integración de EROSKI. Por otro lado, incluso los clientes de un portal dado pueden tener diferentes necesidades. Por ejemplo, el usuario Oscar es muy aprensivo a las condiciones climáticas por lo que siempre consulta el pronóstico del tiempo antes de jar la fecha de un viaje. Esto sólo se aplica a Oscar, y no es contemplado por el portlet ightBooking. Por lo tanto, el Sr. Oscar se ve obligado a moverse fuera del ámbito del portal para satisfacer esta necesidad de datos (por ejemplo, a través de un widget weatherForecast ), y es su responsabilidad pasar los datos necesarios para la consulta del portal al widget. El ejemplo anterior sirve para ilustrar los diferentes contextos en los que la 2 variabilidad puede ser jada y decidida. En concreto, existen tres "reinos de decisión": el proveedor del portlet (por ejemplo, IBERIA). En este caso, el proveedor realiza un análisis profundo del dominio para satisfacer las variaciones del portlet requeridas por todos los usuarios y escenarios donde su portlet puede ser utilizado. el consumidor del portlet (por ejemplo, HALCON). Aquí, el portal del consumidor realiza un análisis de su base de consumidores, y provee los medios al propietario del portal para con gurar el portlet adecuadamente. el usuario nal (por ejemplo, el Sr. Oscar). Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario. Esto es cierto para cualquier aplicación web, y los portlets no son una excepción. Merece la pena mencionar, que estos reinos de decisión no son ortogonales sino complementarios. Todos, el proveedor del portlet, el consumidor del portlet, e incluso, los usuarios nales, deben colaborar para obtener una mejor experiencia en la web. Las secciones siguientes profundizan en cada uno de estos escenarios. 3 Escenario 1: Variabilidad basada en el Provee- dor Este escenario pone la carga de la variabilidad sobre los hombros del proveedor. El proveedor debe realizar un análisis del dominio con el n de comprender los diferentes entornos en los que sus portlets van a ser desplegados. Esto lleva a la noción de Consumer Pro le (o per l del consumidor). El Consumer Pro le incluye no sólo detalles sobre la plataforma del consumidor (por ejemplo, JBoss GateIn, Liferay, eXo Platform), sino también requisitos funcionales planteados por el propietario portal que necesitan ser atendidos por el proveedor del portlet. Mientras que el per l de usuario caracteriza al usuario nal (por ejemplo, edad, nombre, etc.), el Consumer Pro le recoge la idiosincrasia de la organización a través de la cual se está ofreciendo el portlet (por ejemplo, el propietario del portal) en cuanto a la funcionalidad del portlet se re ere. El per l de usuario puede ser dinámico y, por lo tanto, requiere que el portlet pueda ser personalizado en tiempo de ejecución. Por el contrario, el Consumer Pro le se conoce en tiempo de registro, y no siempre es apropiado o posible considerarlo en tiempo de ejecuci ón. En este caso, es mejor personalizar el código en tiempo de desarrollo y producir un portlet especí co para la organización que incluya funcionalidad personalizada. Para este n, se propone el uso de líneas de producto software (SPL) para el desarrollo de portlets. 3 Desarrollo basado en SPL hace referencia a los métodos, herramientas y técnicas para la creación de una colección de sistemas software similares a partir de un conjunto compartido de artefactos software utilizando un medio de producci ón común. En este escenario, ya no tenemos un portlet sino una familia de portlets, y el proveedor de portlet se convierte en la "cadena de montaje" de esta familia. Este trabajo promueve esta visión mediante la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". Al hacer esto, los portlets están más cerca de convertirse en servicios realmente reutilizables y, por lo tanto, permitir la construcción de Arquitecturas Orientadas a Servicios (SOA) usando portlets. Una arquitectura SOA de de ne como "una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales en servicios interoperables estándares que pueden ser combinados y reutilizados de manera ágil para satisfacer las necesidades del negocio" - BEA Systems, Inc. SOA ofrece a las organizaciones una mayor agilidad, ya que pueden desplegar rápidamente nuevos procesos de negocio o modi car los existentes en respuesta a los cambios del mercado. Los portales basados en portlets podrían proporcionar un enfoque ligero a las SOA. La de nición anterior puede reformularse utilizando la terminolog ía de portales como una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales [portlets] en servicios interoperables [portlets remotos pueden comunicarse y compartir datos] estándares [WSRP está basado en los estándares de servicios web] que pueden ser combinados [los portales pueden agregar información de múltiples portlets] y reutilizados de manera ágil [WSRP no requiere esfuerzo de programación] para satisfacer las necesidades del negocio . Aunque un número creciente de organizaciones se están moviendo hacia las SOA muchas están teniendo di cultades para identi- car el primer paso en el proceso. Aquellas empresas que buscan bene ciarse de las SOA pueden utilizar los portales basados en portlets como su primer paso en este camino [9]. Este escenario SOA no sólo requiere interoperabilidad (a través de los estándares de portlets) y la difusión de los portlets (a través de los repositorios de portlets), sino también variabilidad. Los portlets tienden a ser componentes de grano grueso, ya que encapsulan tanto la capa de presentación, como la capa de funcional. Estos componentes de granularidad gruesa tienen menos posibilidades de ser reutilizados "tal cual" [5]. Esto puede poner en peligro la visión de los portlets como servicios reutilizables. Esto introduce las siguientes preguntas de investigación: ¿Cómo se puede aplicar el desarrollo basado en SPL a los portlets? ¿Cuáles serían las implicaciones para el estándar WSRP? 4 4 Escenario 2: Variabilidad basada en el Con- sumidor Los proveedores de portlets no siempre pueden prever todas las necesidades de los consumidores, o algunos portlets podrían necesitar extensiones que no pueden ser soportadas utilizando los mecanismos de parametrización habituales. El etiquetado social es un ejemplo de ello. Los portales, en un grado mayor que otras aplicacionesWeb, tienen la noción de comunidad profundamente arraigada en el interior de su naturaleza. Especí camente, los Enterprise Information Portals nacieron para dar soporte a los empleados dentro de una organización. Por lo tanto, es natural integrar funcionalidades presentes en las redes sociales dentro de estos portales. Entre estas funcionalidades, este trabajo se centra en el etiquetado. La motivación para llevar el etiquetado al lugar de trabajo, admite una doble perspectiva. Desde el punto de vista de la empresa, el etiquetado es un medio económico para compartir y retener conocimiento en el contexto de una organización, previniendo la fuga de datos críticos fuera de la empresa [4]. Desde la perspectiva de un empleado, distintos estudios [11, 1, 8] concluyen que las motivaciones individuales para utilizar el etiquetado en el lugar de trabajo, tales como la creación de un repositorio personal o re-encontrar los recursos propios aún son motivaciones importantes. En este escenario, los etiquetadores (es decir, la comunidad del portal) y las etiquetas son activos del portal. Sin embargo, y a diferencia de los sitios de etiquetado tradicionales, los portales podrían no contener la descripción de todos los recursos susceptibles de ser etiquetados. Por ejemplo, la descripción de los libros o de los hoteles que se ofrecen a través del portal la podría proveer de forma remota, por ejemplo, por Amazon y Expedia, respectivamente. Esta externalización de la descripción de los contenidos no implica que no merezca la pena etiquetar los recursos externos. Esto nos lleva a distinguir entre dos actores: el proveedor de recursos, que mantiene el contenido de los recursos etiquetables (por ejemplo, la descripción del libro en el caso de Amazon), y el consumidor de recursos (es decir, el portal), que mantiene la comunidad de etiquetadores y las etiquetas. De la misma manera en que los portlets adaptan su capa de presentación a las directrices estéticas del portal que los aloja, el etiquetado a través de los portlets también debe adaptarse a las peculiaridades del portal del consumidor. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los portlets ser conscientes de las especi cidades del portal, en concreto, aquellas referentes al etiquetado? 5 Escenario 3: Variabilidad basada en el Usuario La personalización es el proceso de adaptación de las páginas a las características o preferencias individuales de los usuarios de manera que resulten más e caces para satisfacer sus objetivos. Se basan en la teoría de que cada usuario tiene intereses y necesidades únicas. Desafortunadamente, los usuarios normalmente 5 no tienen in uencia en la elección de qué contenido puede ser personalizado o cómo puede este personalizarse. Además, no siempre es fácil para el diseñador prever los distintos contextos y objetivos desde los que se acceden a su aplicación. "Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario" [10]. No hace mucho tiempo, sólo los desarrolladores podían crear aplicaciones. Los usuarios sólo podían utilizar lo que los desarrolladores habían creado antes. Sin embargo, las cosas han cambiado. Con los mashups, los usuarios pueden evitar el departamento de TI y crear sus propias aplicaciones en respuesta a sus propias necesidades. Un mashup es una aplicación web ligera creada por la combinación de información y capacidades de más de una fuente existente para ofrecer nuevas funciones y conocimiento. Nuevas herramientas están actualmente disponibles (por ejemplo, Software AG Presto, IBM Mashup Center, Kofax Kapow) que requieren poca o ninguna participación del departamento de TI y permiten a los usuarios con experiencia crear el mashup que necesitan, cuando lo necesitan. Habilitando a los usuarios de esta manera, se puede reducir el número de aplicaciones que esperan a la cola del departamento de TI para ser creadas, el tiempo y los costos de desarrollo y se puede reducir el costo de crear información personalizada ya que los usuarios pueden adaptar ellos mismos la información a la forma en que la necesitan [3]. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los mashups ser introducidos en los portales basados en portlets? 6 Contribuciones Esta tesis se ha desarrollado en el contexto de la ingeniería, lo que nos empujó a lograr no sólo una contribución académica sino también a mirar la aplicabilidad de estas ideas. Para ello, se proporciona una implementación de las ideas aquí introducidas. En nuestra opinión, esta tesis hace las siguientes aportaciones: 6.0.1 Variabilidad basada en el Proveedor Este trabajo promueve la visión de los portlets como servicios reutilizables mediante la introducción de la noción de Consumer Pro le como una forma de capturar las especi cidades de las diferentes organizaciones, donde el portlet puede ser utilizado. Esto a su vez conduce al uso de un enfoque de desarrollo de portlets basado en SPL y a la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". La solución se ha apoyado en el proyecto WSRP4Java1. 1http: //portals.apache.org/wsrp4j/ 6 6.0.2 Variabilidad basada en el Consumidor Esta tesis explora aquellos medios que pueden ser más adecuados para dar soporte a las características especí cas del consumidor. El etiquetado se utiliza como un ejemplo. Este trabajo argumenta que el etiquetado debe ser ortogonalmente soportado como una funcionalidad transversal encima de los portlets. El principal reto se basa en la coherencia tanto en el back-end (esto es, el uso de una estructura común de datos, por ejemplo, un conjunto común de etiquetas), y el front-end (esto es, las interacciones con la funcionalidad de etiquetado deben ser soportadas de forma homogénea a lo largo de todo el portal utilizando estilos de presentación similares). El mecanismo de eventos de los portlet y las anotaciones RDFa se utilizan para cumplir con este requisito. Un ejemplo sobre Liferay ilustra la viabilidad del enfoque. 6.0.3 Variabilidad basada en el Usuario El enfoque presentado introduce mashups como un mecanismo de personalizaci ón adicional mediante el cual los usuarios del portal pueden complementar los servicios del portal (es decir, los portlets) con sus propias necesidades de información. El enfoque se implementa sobre Liferay como la plataforma de portales utilizando los portlets como la tecnología para soportar los servicios del portal y XBL como que la tecnología de integración. Para facilitar la adopción del enfoque se ha desarrollado una herramienta visual que oculta los tecnicismos de XBL a los usuarios. 7 Conclusiones El protocolo WSRP describe la conversación entre los proveedores de portlets y los consumidores que actúan en nombre de los usuarios nales: los proveedores son los servicios web con capa de presentación que alojan los portlets y son capaces de procesar las solicitudes de markup y las de interacción del usuario con los portlets, los consumidores utilizan estos servicios web como parte de las vistas que presentan a los usuarios nales y gestionan las interacción de los usuarios nales con la capa de presentación de los portlets, los usuarios nales son los clientes de los consumidores Estos roles constituyen los diferentes contextos en los que la variabilidad de los portlets remotos se puede jar y decidir. el proveedor de portlet. En este caso, el proveedor de portlets lleva a cabo un análisis profundo del dominio y proporciona a los consumidores un conjunto cerrado de variantes entre las que elegir. 7 el consumidor portlet. Los consumidores de portlets también pueden crear y añadir sus propias variantes especí cas del producto, por ejemplo, para tener en cuenta los requisitos que para ser satisfechos requieren el uso de funcionalidad externa. el usuario nal. Hay una tendencia creciente para proporcionar variabilidad a los usuarios nales (por ejemplo, mecanismos a través de plugins). Sin embargo, no podemos esperar que los usuarios nales puedan editar y compilar el código fuente. Esta tesis aborda el reto de soportar variabilidad para cada uno de estos escenarios

Education, Employment, and Health Outcomes for Black Boys and Young Men: Opportunities for Research and Advocacy Collaboration

In May 2013, CLASP's Partnership Circle and the Scholars Network on Black Masculinity convened 32 nationally recognized researchers and policy advocates, who identified areas of potential influence in crafting policy solutions for black male adolescents and opportunities to act individually and collectively to advance work in these areas

Citizen Participation in Rulemaking: Past, Present, and Future

Administrative law scholars and governmental reformers argue that advances in information technology will greatly expand public participation in regulatory policymaking. They claim that e-rulemaking, or the application of new technology to administrative rulemaking, promises to transform a previously insulated process into one in which ordinary citizens regularly provide input. With the federal government having implemented several e-rulemaking initiatives in recent years, we can now begin to assess whether such a transformation is in the works-or even on the horizon. This paper compares empirical observations on citizen participation in the past, before e-rulemaking, with more recent data on citizen participation after the introduction of various types of technological innovations. Contrary to prevailing predictions, empirical research shows that e-rulemaking makes little difference: citizen input remains typically sparse, notwithstanding the relative ease with which individuals can now learn about and comment on regulatory proposals. These findings indicate that the more significant barriers to citizen participation are cognitive and motivational. Even with e-rulemaking, it takes a high level of technical sophistication to understand and comment on regulatory proceedings. Moreover, even though information technology lowers the absolute cost of submitting comments to regulatory agencies, it also dramatically decreases the costs of a wide variety of entertainment and commercial activities that are much more appealing to most citizens. Given persistent opportunity costs and other barriers to citizen participation, even future e-rulemaking efforts appear unlikely to lead to a participatory revolution, but instead can be expected generally to deliver much the same level of citizen involvement in the regulatory process

IMPLEMENTING E-LEARNING IN THE ROMANIAN EDUCATIONAL SYSTEM - A PRIORITY IN THE CONTEXT OF EU INTEGRATION

This paper intends to examine the development of e-Learning in Romania and to evaluate the gap between Romania and other members of the European Union (EU). Considering that Romania is part of the EU since 2007, it is imperative to achieve, in the shortest possible time, a real convergence with other member states. This requires finding the most effective ways to accelerate the development and increase the competitiveness. Using extensive IT&C technologies represent such a way, and public services – education, too – are among the development priorities on the agendas of all policies, both nationally and European. Thus, the subject treated in the paper is not only present but also of strategic importance for the immediate future of Romania.e-learning, e-education, IT&C

From access and integration to mining of secure genomic data sets across the grid

The UK Department of Trade and Industry (DTI) funded BRIDGES project (Biomedical Research Informatics Delivered by Grid Enabled Services) has developed a Grid infrastructure to support cardiovascular research. This includes the provision of a compute Grid and a data Grid infrastructure with security at its heart. In this paper we focus on the BRIDGES data Grid. A primary aim of the BRIDGES data Grid is to help control the complexity in access to and integration of a myriad of genomic data sets through simple Grid based tools. We outline these tools, how they are delivered to the end user scientists. We also describe how these tools are to be extended in the BBSRC funded Grid Enabled Microarray Expression Profile Search (GEMEPS) to support a richer vocabulary of search capabilities to support mining of microarray data sets. As with BRIDGES, fine grain Grid security underpins GEMEPS

Towards an Expert Network in Open Standards and Open Source Software: Research, Expertise and Synergy for Open and Libres Standards and Software (RESOLL) - Version 2.0

CIRANO and its partners are proposing the creation of an Expert Network in Open Standards and Open Source Software (Research, Expertise and Synergy for Open and Libres Standards and Software-RESOLL), which would be a partnership between information technology research centres, government and private user organizations, and businesses working in the field. The network will conduct studies and pilot projects that integrate computer solutions based on open standards and open source software, mainly in e-government fields such as health, education, and scientific research, as well as municipal and quasi-public services and business processes for SMEs. The knowledge, expertise and tools thus developed will be disseminated in a number of ways in order to Quebec and Canadian expertise in the field. RESOLL will also have economic and strategic benefits in that it will put the new economic model to the test in terms of open standards and open source software as well as the reuse of software components by organizations. Background The development of on-line government services and e-business is a priority for governments and businesses of all sizes. It requires considerable spending and significant strategic and organizational changes. Of the many information technology solutions available, the use of open standards and open source software is often brought up by those in the know. Although the Internet and many world-renowned software programs were developed largely from open standards and open source software, there is still a need to study, and above all prove the advantages of this approach for public and quasi-public organizations as well as small to medium-sized businesses. It is essential to identify the needs of these organizations, document best practices, experiment with open source software solutions, evaluate the performance of the software and share the knowledge and know-how of Quebec and Canadian research centres and businesses. RESOLL Goals he main goal of the Expert Network on Open Standards and Open Source Software (RESOLL) is to give people an understanding of the benefits of open standards and open source software and suggest an intelligent and advantageous use of them for public and quasi-public organizations and SMEs. More specifically, the goals are as follows: Document and share government and industry policies, strategies, and practices with respect to the use and development of adaptive software and open source software, defining open standards, open source software, adaptive software, and proprietary software; Adapt these practices and share the different methods with partners and the IT management and development communities in government and business; Establish innovative prototypes and pilot projects in order to test and demonstrate the advantages and features of this approach; Develop the expertise of Quebec and Canadian organizations in the field and create synergy between them and their users; P ublish and share the findings of the work, contribute to the enrichment of a collective software asset base available to public and quasi-public organizations and SMEs while explaining the legal issues involved in the various types of licences and electronic services. Process ESOLL is a multilateral partnership founded on the excellence of partners in their respective field. The RESOLL process will be based on the needs of its partners and users. Once these needs have been identified, research will be conducted to identify available solutions, adapt them through an integration process and alpha test them. This would be followed by a pilot project as required by the organizations and businesses. The pilot project will be implemented and evaluated in order to learn from it and ensure that necessary adjustments are made. Solutions thus obtained will be implemented as electronic services either by the client organization’s IT department or by a business partner. It is up to each organization to select their service provider. RESOLL will encourage the transfer of developed tools and services to partners for complete autonomy. Each project will have its own budget, funded by client partners. RESOLL will use part of its operating budget to start projects and develop a start-up asset base for its activities. Expectations and Deliverables The expectations of RESOLL partners and the team can be expressed by the achievement of their goals. RESOLL’s actions will quickly lead to concrete results. The deliverables will be: Policy and position papers to help partners make clear and informed decisions; Needs analyses and suggested solutions; Software solutions based on open standards and open source software integrated into experimental electronic services; Pilot project experiments that combine strategies, plans, software solutions, project support, evaluation and recommendations; Studies and interpretation documents for different types of licences and software; Collaborative Web site for sharing documents and open source software developed in the context of RESOLL projects or available on the Internet, with comments and explanations; Information and knowledge sharing activities for RESOLL and its partners (conferences, workshops, training, etc.). Partners RESOLL is a multilateral partnership. The partners that have been asked to become involved are: CIRANO, CRIM, RISQ, the governments of Quebec and Canada, Industry Canada, university researchers, Canadian and Quebec software and information technology companies, and not-for-profit user organizations from the software and information technology fields. Budget ESOLL’s master infrastructure budget will make it possible to establish a small coordination team involving part-time resources seconded from their parent organizations. We plan to obtain general financing from government and the businesses involved. The individual projects will provide their own financing. Other Benefits RESOLL will contribute to Quebec’s and Canada’s world leadership by sharing the results of its work. It will contribute to the eventual creation of resources that will enable partner companies to commercialize services based on open source software.Open standard, free software, open software, FOSS, e-government, business process, small and medium enterprises,