scieee AI-readable full text Open interactive document viewer

Actas del Taller de Trabajo Zoco’09 / JISBD Integración de Aplicaciones e Información Empresarial XIV Jornadas de Ingeniería del Software y Bases de Datos San Sebastián, 8 de septiembre de 2009

Álvarez, José L.; Arjona, José L.; Fernández de Viana, Iñaki; Corchuelo Gil, Rafael; Ruiz Cortés, David; Rivero, Carlos; Hernández Salmerón, Inmaculada Concepción

Full text

Actas del Taller de Trabajo Zoco’09 / JISBD Integración de Aplicaciones e Información Empresarial XIV Jornadas de Ingeniería del Software y Bases de Datos San Sebastián, 8 de septiembre de 2009 http://www.tdg-seville.info/cfp/zoco/ Organizadores José L. Álvarez, José L. Arjona, Iñaki Fernández de Viana (Universidad de Huelva) Rafael Corchuelo, David Ruiz, Carlos Rivero, Hassan A. Sleiman, Inmaculada Hernández (Universidad de Sevilla) Ponentes Eduardo Martín Rojo y Vicente L Patricia Jiménez (Universidad de Huelva) Carlos G. Figuerola, José Luis Alonso Berrocal y A Inma Hernández (Uni -González, Beatriz Pérez-León (Universidad de Valladolid) y M. Luisa Alvite-Díez (Universidad de León) s Cuadrado (Telefónica Investigación y Desarrollo), Eduardo Villoslada de la Torre (Telefónica Investigación y Desarrollo, Universidad de Valladolid) y Alberto Peláez -Delgado, Amine Kerzazi y José F. Aldana- Calero (Universidad de Castilla– rsidad Garijo (Telefónica I+D), Juan Pavón, Carlos Rodríguez y Damiano Spina (Universidad Complutense de Madrid) Agradecimiento Financiación Proyecto IntegraWeb (TIN2007-64119, P07-TIC-02602, P08-TIC-4100) ©2009, José L. Álvarez, José L. Arjona, Rafael Corchuelo, David Ruiz. Los derechos de copia están permitidos para propósitos académicos y privados. Es necesario el permiso expreso de los propietarios del copyright para su republicación. Índice Prólogo del taller, I José L. Álvarez, José L. Arjona, Rafael Corchuelo y David Ruiz Extracción de Datos de Sitios de la Web Profunda Anotados Semánticamente, 1 Eduardo Martín Rojo y Vicente Luque Centeno Information Extraction from the World Wide Web, 11 Hassan A. Sleiman Optimizando FOIL para la Extracción de Información de la Web, 20 Patricia Jiménez Mejoras en la recuperación web combinando campos, 30 Carlos G. Figuerola, José Luis Alonso Berrocal y Angel Zazo Rodríguez Intelligent Web Navigation, 36 Inma Hernández Web Navigation Automation in AJAX Websites, 46 Paula Montoto, Alberto Pan, Juan Raposo, Fernando Bellas y Javier López SKOS en la integración de conocimiento en los sistemas de información jurídica, 56 M. Mercedes Martínez-González, Beatriz Pérez-León y M. Luisa Alvite-Díez Generación de Tesauros basado en Media Wiki, 63 Ana Flores Cuadrado, Eduardo Villoslada de la Torre y Alberto Peláez Gutiérrez Un Editor de Modelos OWL-S: OWL-S Modeller, 72 Ismael Navas-Delgado, Amine Kerzazi y José F. Aldana-Montes A Model Transformation-based Technique for Flexible XML Data Source Integration, 82 María Pérez, Ismael Sanz, María José Aramburu y Rafael Berlanga Integración de Aspectos de Calidad de Datos en Sistemas de Información, 92 Ismael Caballero, Mª Ángeles Moraga y Coral Calero Context-aware and Home Care: Improving the quality of life for patients living at home, 102 Juan A. Fraile, Javier Bajo y Juan M. Corchado Developing Advanced Services for SMEs using Service-Centric Tools: Experiences and Challenges, 112 Francisco J. Garijo, Juan Pavón, Carlos Rodríguez y Damiano Spina Pr´ ologo del taller Jos´e L. ´ Alvarez1, Jos´e L. Arjona1, Rafael Corchuelo2y David Ruiz2 1Universidad de Huelva Dep. de Tecnolog´ıas de la Informaci´on Escuela Polit´ecnica Superior. Ctra. Huelva-La R´abida. Palos de la Frontera 21071 {alvarez,jose.arjona}@diesia.uhu.es 2Universidad de Sevilla Dep. de Lenguajes y Sistemas Inform´aticos ETSI Inform´atica. Avda. Reina Mercedes, s/n. Sevilla 41012 {corchu,druiz}@us.es 1 Motivaci´on Nuestro inter´es principal es estudiar los problemas relacionados con la integraci´on de aplicaciones web que tan s´olo ofrecen una interfaz de usuario. Estas aplicaciones suelen ser fuentes de datos muy valiosas, pero no resulta f´acil aprovecharlas a gran escala debido a las dificultades que supone integrarlas dentro de procesos de negocio automatizados. Desde el punto de vista de la investigaci´on, se trata de un tema que est´a atrayendo a diversas comunidades: la de Base de Datos, por ejemplo, est´a prestando mucha atenci´on al desarrollo de lenguajes de consulta estructurados espec´ıficos para la Web; la de Inteligencia Artificial, est´a m´as centrada en el dise˜no de herramientas que permitan extraer la informaci´on de las p´aginas web y dotarla de un significado bien definido usando ontolog´ıas; la de Miner´ıa de Datos tambi´en ha mostrado inter´es por este problema y centra su esfuerzo en el desarrollo de t´ecnicas de verificaci´on de informaci´on; etc´etera. Sin duda alguna, creemos que una de las comunidades que m´as puede beneficiarse de todos estos avances multidisciplinares es la de los Servicios Web, ya que las aplicaciones que tan s´olo ofrecen una interfaz de usuario suelen suponer una complicaci´on en muchos casos insalvable a la hora de dise˜nar un proceso de negocio basado en est´andares como, por ejemplo, BPMN/BPEL. Para la comunidad de Ingenier´ıa del Software, este tipo de aplicaciones tambi´en supone un reto interesante ya que hasta el momento no existe ninguna metodolog´ıa adaptada a este tipo de problemas. Zoco’09 contin´ua una andadura que comenz´o en 2001 con el objetivo de ofrecer un foro apropiado a los investigadores interesados en el desarrollo de aplicaciones de negocio en la Web. En esta edici´on ha pretendido ser un punto de encuentro multidisciplinar en el que diversas comunidades hayan podido discutir propuestas relacionadas con la integraci´on de aplicaciones web. 2 Contribuciones En total han sido trece las contribuciones aceptadas en esta edici´on del taller. En su conjunto creemos que proporcionan una visi´on bastante amplia del trabajo Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 I que se est´a realizando en el campo de la integraci´on en distintos grupos de investigaci´on y, en algunos casos, en empresas de nuestro entorno. 1. El primer trabajo, de Eduardo Mart´ın Rojo y Vicente Luque Centeno, de la Universidad Carlos III de Madrid, presenta un modelo de anotaci´on para sitios de la Web Profunda que pueda ser utilizado para la extracci´on de informaci´on. Estas anotaciones permitir´an la creaci´on de Wrappers Web m´as adaptables a los posibles cambios estructurales del sitio web accedido. 2. Hassan A. Sleiman, de la Universidad de Sevilla, presenta un framework de comparaci´on de extractores de informaci´on de la web semi-estructurada, este tipo de frameworks reduce los costes de an´alisis y de construcci´on de nuevos extractores, facilitando la integraci´on de informaci´on de la web en los procesos de negocio. 3. Patricia Jim´enez, de la Universidad de Huelva, presenta un conjunto de mejoras para aplicar al algoritmo FOIL cuando se emplea en extractores de informaci´on de p´aginas web semi-estructuradas. 4. Carlos G. Figuerola, Jos´e Luis Alonso Berrocal y Angel Zazo Rodr´ıguez, de la Universidad de Salamanca, describen algunas de las actividades del grupo de investigaci´on REINA en torno a la recuperaci´on de informaci´on web. Estas actividades se han centrado en probar la capacidad de recuperaci´on que puede esperarse de diversos elementos informativos presentes en las p´aginas web, adem´as del texto que el usuario visualiza normalmente en su navegador. 5. El cuarto trabajo presentado por Inma Hern´andez, de la Universidad de Sevilla, estudia las diferentes propuestas que existen actualmente para navegar por p´aginas web de forma autom´atica, adem´as, se presenta un estudio experimental que demuestra que las t´ecnicas actuales son ineficientes a la hora de navegar. 6. Paula Montoto, Alberto Pan, Juan Raposo, Fernando Bellas y Javier L´opez, de la Universidade da Coru˜na, proponen una serie de t´ecnicas para tratar la navegaci´on web en aplicaciones complejas basadas en AJAX. Aunque las herramientas existentes tratan p´aginas web con AJAX, dichas herramientas presentan limitaciones significativas en su usabilidad y la habilidad para tratar con p´aginas web complejas. 7. M. Mercedes Mart´ınez-Gonz´alez, Beatriz P´erez-Le´on, de la Universidad de Valladolid, y M. Luisa Alvite-D´ıez, de la Universidad de Le´on, afirman que el uso de est´andares asociados a la Web Sem´antica no es suficiente para garantizar totalmente la integraci´on de las herramientas conceptuales utilizadas. Demuestran dicha afirmaci´on en el caso de los sistemas de informaci´on jur´ıdica. 8. Ana Flores Cuadrado, de Telef´onica Investigaci´on y Desarrollo, Eduardo Villoslada de la Torre, de Telef´onica Investigaci´on y Desarrollo y la Universidad de Valladolid, y Alberto Pel´aez Guti´errez, de Telef´onica Soluciones, definen un algoritmo que permite materializar la estructura conceptual de la Wikipedia y sus relaciones para construir un tesauro. 9. Ismael Navas-Delgado, Amine Kerzazi y Jos´e F. Aldana-Montes, de la Universidad de M´alaga, abordan el dise˜no e implementaci´on de una extensi´on Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 II de WSMO Studio para permitir el dise˜no de anotaciones de servicios mediante OWL-S. De esta forma, los desarrolladores de servicios Web Sem´anticos pueden hacer uso de un mismo entorno para producir servicios anotados con ambas propuestas. 10. Mar´ıa P´erez, Ismael Sanz, Mar´ıa Jos´e Aramburu y Rafael Berlanga, de la Universitat Jaume I de Castell´o, presentan una t´ecnica para seleccionar m´etodos de ranking apropiados para fuentes de datos complejas usando transformaciones de modelos. 11. Ismael Caballero, Ma´ Angeles Moraga y Coral Calero, de la Universidad de Castilla-La Mancha, plantean algunos de los retos de investigaci´on que est´an afrontando, como por ejemplo la posibilidad de aplicar los principios de LinkedData para anotaciones de calidad de datos, o c´omo aplicar los resultados que obtenidos a los datos almacenados en bases de datos heredadas. 12. Juan A. Fraile, Javier Bajo, de la Universidad Pontificia de Salamanca, y Juan M. Corchado, de la Universidad de Salamanca, presentan un sistema multiagente que facilita la realizaci´on de tareas diarias para personas en un entorno con conocimiento del contexto. 13. Francisco J. Garijo, de Telef´onica I+D, Juan Pav´on, Carlos Rodr´ıguez y Damiano Spina, de la Universidad Complutense de Madrid, presentan las experiencias y resultados obtenidos para ofrecer sofisticados Business Support Systems en pymes. 3 Comit´es 4 Programa A continuaci´on aparecen los nombres y afiliaciones del comit´e de programa y de organizaci´on de este taller. Damos las gracias a todos ellos por su apoyo y contribuci´on desinteresada para conseguir que esta edici´on sea un ´exito. 4.1 Acad´emico Joaqu´ın Adiego, Universidad de Valladolid Jos´e F. Aldana, Universidad de M´alaga C´esar J. Acu˜na, Universidad Rey Juan Carlos Rafael Berlanga, Universidad Jaume I Fernando Bellas, Universidad de la Coru˜na Ismael Caballero, Universidad de Castilla-La Mancha Juan M. Corchado, Universidad de Salamanca Carlos G. Figuerola, Universidad de Salamanca Vicente Luque, Universidad Carlos III de Madrid Mercedes Mart´ınez, Universidad de Valladolid Juan Pav´on, Universidad Complutense de Madrid Miguel Toro, Universidad de Sevilla Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 III 4.2 Empresa Pablo Adanero, Indevia Ana Flores Cuadrado, Telef´onica I+D Javier L´opez Mato, Denodo Technologies Alberto Pan, Denodo Technologies Antonio J. S´aenz, Isotrol 5 Organizaci´on Jos´e L. ´ Alvarez, Universidad de Huelva Jos´e L. Arjona, Universidad de Huelva Rafael Corchuelo, Universidad de Sevilla I˜naki Fern´andez de Viana, Universidad de Huelva Inma Hern´andez, Universidad de Sevilla Carlos Rivero, Universidad de Sevilla David Ruiz, Universidad de Sevilla Hassan A. Sleiman, Universidad de Sevilla Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 IV Extracci´on de Datos de Sitios de la Web Profunda Anotados Sem´anticamente Eduardo Mart´ın Rojo, Vicente Luque Centeno Universidad Carlos III de Madrid Av. Universidad 30, 28911 Legan´es (Madrid), Espa˜na {emartin,vlc}@it.uc3m.es Resumen La navegaci´on y recolecci´on de informaci´on de forma autom´atica de p´aginas de la Web Profunda requiere de la utilizaci´on de Wrappers Web que permitan simular la interacci´on realizada por usuarios humanos; sin embargo, este tipo de aplicaciones poseen algunos problemas debido a que su implementaci´on posee una fuerte dependencia con la estructura del sitio web accedido y a que su c´odigo fuente requiere de un mantenimiento constante. En este trabajo proponemos un modelo de anotaci´on para sitios de la Web Profunda que pueda ser utilizado para la extracci´on de informaci´on. Las anotaciones realizadas con nuestro modelo se expresan desde el punto de vista del cliente permitiendo a usuarios finales y a terceras partes el desarrollo de sus propias anotaciones para cualquier sitio web. Esta anotaciones permitir´an la creaci´on de Wrappers Web m´as adaptables a los posibles cambios estructurales del sitio web accedido. 1. Introducci´on Actualmente los sitios Web m´as populares proporcionan a sus usuarios de herramientas de desarrollo que permiten la creaci´on de aplicaciones capaces de acceder a algunas de sus funcionalidades (por ejemplo, eBay Developers Program1); y frecuentemente dichas funcionalidades son ofrecidas por medio de servicios Web que permiten ser accedidos con aplicaciones para mashups como Google Mashups2,Yahoo Pipes3or Microsoft Popfly4. Sin embargo, la inmensa mayor´ıa de sitios Web est´an enfocados a ser manejados ´unicamente por usuarios humanos, con lo que no proveen de este tipo de herramientas. El acceso a este tipo de sitios se realiza por medio de los llamados Wrappers Web[5]. Algunos de los principales problemas de los Wrappers Web son: en primer lugar, requieren que los desarrolladores posean un alto nivel de conocimiento de la 1http://developer.ebay.com/ 2http://www.googlemashups.com/ 3http://pipes.yahoo.com 4http://www.popfly.com Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 1 estructura del sitio Web accedido dado que los Wrappers son soluciones espec´ıficas para cada sitio Web concreto; y en segundo lugar, los Wrappers Web requieren de un contante mantenimiento que les permita ser capaces de adaptarse a los cambios futuros. La evoluci´on de las herramientas de desarrollo para Wrappers Web se ha dirigido a intentar resolver estas debilidades y al mismo tiempo hacer posible una integraci´on de datos Web de fuentes heterog´eneas de una manera m´as f´acil. Algunos ejemplos de herramientas de desarrollo de Wrappers Web son las herramientas para creaci´on de soluciones espec´ıficas como GreaseMonkey5y Ubiquity6, las herramientas de usuario final que permiten la utilizaci´on de ciertos elementos de lenguaje natural como Chickenfoot7, o tambi´en herramientas gr´aficas como OpenKapow RoboMaker8. La principal caracter´ıstica com´un a todas las soluciones de desarrollo de los Wrappers Web en la actualidad es que, aunque proveen de un manejo sencillo, siempre implican un tipo de desarrollo con fuerte dependencia respecto de la estructura del sitio Web. En el trabajo que presentamos a continuaci´on hemos definido una formalizaci´on que permite anotar sem´anticamente la estructura de un sitio Web para representar la navegaci´on a trav´es del sitio. Estas anotaciones poseen a su vez referencias que permiten localizar los fragmentos de informaci´on m´as importantes del sitio Web durante la navegaci´on; utilizando las actuales herramientas de desarrollo de Wrappers Web nuestras anotaciones permitir´an la implementaci´on de Wrappers basados en el modelo del sitio web que eviten el solapado con la estructura del sitio. Adem´as, el mantenimiento requerido por los cambios producidos en el sitio Web quedar´an aislados dentro de la capa del modelo. En nuestro trabajo hemos elegido utilizar el punto de vista del cliente para la elaboraci´on de los modelos de navegaci´on de los sitios Web debido a que: El punto de vista del cliente permite a terceras partes y usuarios finales participar y colaborar en la creaci´on de anotaciones sobre cualquier sitio Web, ya que no requieren acceder al servidor. No es intrusivo; no requiere cambiar el sitio Web que est´a siendo anotado como lo requerir´ıan otros m´etodos de anotaci´on como RDFa[9] o Microformats[8]. 2. Trabajos Relacionados y Contribuci´on La generaci´on del modelo de navegaci´on de Web Profunda es tratado por [10], donde los auotres generan un modelo de navegaci´on donde utilizan b´usqueda de palabras clave para identificar las diferentes p´aginas de la Web Profunda. Otro trabajo, m´as enfocado a la interacci´on con sitios de la Web Profunda es Trascendence[1], un sistema que permite a los usuarios generalizar sus consultas sobre un formulario de b´usqueda para poder expandir su espacio de b´usqueda. 5http://www.greasespot.net/ 6http://ubiquity.mozilla.com/ 7http://groups.csail.mit.edu/uid/chickenfoot/ 8http://openkapow.com/ Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 2 Shop of Books Web Site RSS Interesting Books transition0 ACTION enter(element0, $SEARCHED_PRODUCT); semantic orderedActions ACTION click(element1); semantic nextAction INPUT $SEARCHED_PRODUCT type rdfs:String description String representing product semantic ADD({this log:content ?text} log:implies {:searchText a :Variable. :searchText log:content ?text.}) inputs QUERY GOAL DEFINITION sparql SELECT ?price FROM NAMED <http://rss> FROM NAMED <http://shop> WHERE { GRAPH <http://rss> { ?product a shop:Product . ?product shop:productTitle ?title.} GRAPH <http://shop>{ ?product2 a shop:Product . ?product2 :searchedBy ?title . ?product2 :productPrice ?price .}} rss_state0 FRAGMENT element0 locatedBy //item semantic ADD(this a shop:ListOfProducts.) ADD(this shop:searchedBy :searchText.) fragmentOf FRAGMENT element1 locatedBy [$INDEX] semantic ADD(this a shop:Product.) fragmentOf INPUT $BOOK_INDEX type rdfs:Integer description Position of book inside list semantic ADD({this log:content ?text} log:implies {:positionSelected a :Variable. :positionSelected log:content ?text.}) inputs FRAGMENT element2 locatedBy /title semantic ADD({this log:content ?text . this :fragmentOf ?father.} log:implies {?father shop:productTitle ?text.}) fragmentOf Figura 3. Ejemplo de realizaci´on de consultas entre mapas diferentes 5. Trabajos Futuros Acceder e integrar datos procedentes de fuentes Web heterog´eneas no estructuradas es un problema que actualmente se resuelve por medio de la realizaci´on de Wrappers Web a pesar de sus carencias. Los Wrappers Web son herramientas que pueden ser utilizadas para estructurar la informaci´on obtenida de fuentes no estructuradas y ponerla a disposici´on de la Web de Datos. Pensamos que el desarrollo de wrappers debe ser adaptado a este nuevo entorno de datos enlazados utilizando definiciones de Wrappers orientados a sem´antica, e implementaciones no enfocadas al sitio Web concreto. Para lograr esto, estamos interesados en la investigaci´on de lenguajes m´as potentes y herramientas de desarrollo para esta nueva aproximaci´on de desarrollo de Wrappers sem´anticos. Estamos interesados en continuar trabajando en la integraci´on de ontolog´ıas con las implementaciones de Wrappers sem´anticos con el objeto de aprovechar los conceptos comunes entre diferentes sitios web. La misma implementaci´on de Wrapper sem´antico puede ser utilizada en cualquier sitio web que ha sido anotado utilizando la misma ontolog´ıa. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 9 6. Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Educaci´on y Ciencia, proyecto ITACA No.TSI2007-65393-C02-01. Referencias 1. Jeffrey P. Bigham, Anna C. Cavender, Ryan S. Kaminsky, Craig M. Prince, and Tyler S. Robison. Transcendence: enabling a personal view of the deep web. In IUI ’08: Proceedings of the 13th international conference on Intelligent user interfaces, pages 169–178, New York, NY, USA, 2008. ACM. 2. Michael Bolin and Robert C. Miller. Naming page elements in end-user web automation. SIGSOFT Softw. Eng. Notes, 30(4):1–5, 2005. 3. Michael Bolin, Matthew Webber, Philip Rha, Tom Wilson, and Robert C. Miller. Automation and customization of rendered web pages. In UIST ’05: Proceedings of the 18th annual ACM symposium on User interface software and technology, pages 163–172, New York, NY, USA, 2005. ACM. 4. Jeremy J. Carroll, Christian Bizer, Pat Hayes, and Patrick Stickler. Named graphs, provenance and trust. In WWW ’05: Proceedings of the 14th international conference on World Wide Web, pages 613–622, New York, NY, USA, 2005. ACM. 5. Sudarshan Chawathe, Hector Garcia-molina, Joachim Hammer, Kelly Irel, Yannis Papakonstantinou, Jeffrey Ullman, and Jennifer Widom. The tsimmis project: Integration of heterogeneous information sources. In In Proceedings of IPSJ Conference, pages 7–18, 1994. 6. Darris Hupp and Robert C. Miller. Smart bookmarks: automatic retroactive macro recording on the web. In UIST ’07: Proceedings of the 20th annual ACM symposium on User interface software and technology, pages 81–90, New York, NY, USA, 2007. ACM. 7. David Huynh, Stefano Mazzocchi, and David Karger. Piggy Bank: Experience the Semantic Web inside your web browser, volume 5, pages 16–27. Elsevier Science Publishers B. V., Amsterdam, The Netherlands, The Netherlands, 2007. 8. Rohit Khare and Tantek Celik. Microformats: a pragmatic path to the semantic web. pages 865–866, 2006. 9. W3C. Rdfa primer. W3C Working Group Note 14 October 2008, October 2008. 10. Yang Wang and Thomas Hornung. Deep web navigation by example. In Tomasz Kaczmarek Marek Kowalkiewicz Tadhg Nagle Jonny Parkes Dominik Flejter, Slawomir Grzonkowski, editor, BIS 2008 Workshop Proceedings, Inssbruck, Austria, 6-7 May 2008, pages 131–140. Department of Information Systems, Pozna, University of Economics, 2008. 11. WebTLab. Site annotation demo. http://corelli.gast.it.uc3m.es/siteannotation. 12. WebTLab. Site annotation ontology. http://corelli.gast.it.uc3m.es/siteannotation/ontology.owl. 13. Jeffrey Wong and Jason I. Hong. Making mashups with marmite: towards enduser programming for the web. In CHI ’07: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 1435–1444, New York, NY, USA, 2007. ACM. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 10 Information extraction from the World Wide Web ? Hassan A. Sleiman Universidad de Sevilla ETSI Inform´ atica Avda. Reina Mercedes, s/n. Sevilla 41012 Spain [email protected] Abstract. The World Wide Web is an enormous and a growing source of information presented in a human friendly language called Html. Unfortunately, querying and accessing this information by software agents is not an easy task, so web information extractors are used. Currently, there is a variety of algorithms to build web information extractors, but none of them is universally applicable. There is not a common software framework to develop them. This has resulted in proposals that range in complexity, precision and recall, but having diverging interfaces, which makes it difficult to reuse or integrate them. As a result, few side-by-side comparisons are available, but none of them is complete. We argue that the key is the absence of a unifying framework in which researchers can develop their proposals so that they can be assessed properly. Devising and implementing such a framework would be an ultimate tool to help reduce costs at integrating web information into automatic business processes. In this paper we report on our first version of this framework for information extractors. Key words: Information extraction, Enterprise Information Integration. 1 Introduction The World Wide Web is a growing database in which a great amount of information is present. Unfortunately, querying and accessing these data by software agents is not a simple task since data present in web pages is provided using human friendly formats. This type of codification makes it easier for humans to understand and browse the Web, but makes the incorporation and the use of this data by automated processes very difficult. Some solutions for this problem can be the use of the semantic web [22], which is still a vision, or the use of web services [3], but till these proposals are taken into consideration by all the web sites and are completely specified, one solution is to use information extractors to fill the gap and help us to transform data present in the web to completely structured data usable by automated processes. There exists a great number of proposals for information extraction algorithms, but unfortunately none of them can be considered as a perfect solution. Information extractors such as [15], [1], [6], [4], [10], [12] and [24], are usually designed and built providing distinct interfaces, thus complicating the task of integration of these algorithms inside enterprise applications. ?Partially funded by the Spanish National R&D&I Plan under grants TIN2008-04718, and the Andalusian Local Government under grants P07-TIC-02602, and P08-TIC-4100. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 11 Suppose we wish to integrate web information into a business process of ours, then one of these tools should be integrated into our enterprise application, but before integrating it, we would like to evaluate existing algorithms to choose the one that fits our case better. One of these three tasks should be performed: study existing surveys that compare information extractors, ask authors for these tools and then work on integrating them into our system, or even develop these algorithms to test them over the web sites we are going to work over. At the end of any of the previous tasks, an information extractor is chosen and integrated, but all of these tasks are tedious and expensive. The variety of information extractors motivated the existence of many surveys to compare these extraction algorithms and tools such as: [2], [11], [20] and [8]. However, these surveys use taxonomies do not provide new information about the algorithms, and although effectiveness and efficiency are studied, they is not a side-by-side comparison. Besides, the results presented in algorithms’ proposals are performed over distinct web sites, so these results are not comparable between each other. Since no decision can be taken based on the comparison presented by surveys, using information extraction tools for comparison should be considered. We need the tools and the implementations of all the extraction algorithms to test and compare their efficiency and effectiveness. Existing tools are developed using different technologies and different libraries, thus the results of our tests are not reliable since technology conditions are distinct. Also, these tools provide different interfaces and integrating the chosen one into our enterprise application could be time and resource costly. Implementing all extraction algorithms is a very high costing task, user should study deeply a great number of algorithms, and develop them since there is not any software framework to facilitate this job. We think that the solution to this problem is the creation of an information extraction framework where researchers can develop their proposals and where users can compare these proposals and select the most adequate information extraction algorithm for their case. Our proposal is to create an information extraction framework for semi-structured web pages. This framework reduces the costs of the integration of web information into business processes, reduces costs for developing new extraction algorithms and for testing and comparing these algorithms. This paper is organised as follows. After showing the motivation in the introduction Section 1, Section 2 introduces information extractors for semi-structured web pages and then section 3 describes our information extraction comparison framework. Section 4 presents the conclusions and our future work. 2 Types and Techniques in Web Information Extraction We can differentiate between three types of web pages: non-structured, semi-structured and structured web pages. Non structured web pages are those in which the info of interest is within free text. A common property for these types of pages is that given a set of similar non-structured web pages, no common pattern can be induced. In other words, free texts have no common pattern or rule that may help us to extract information from them. For this type of web pages, special information extractors are needed such as [23], [18] and [21]. These information extractors analyse and preprocess text, such as Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 12 + Template Web page - Data Results + Template Web page - Data Results Fig.1. Semi-structured web page creation. performing Part of Speech Tagging (POS Tagging) and gaseeters or Entity recognisers, and then identify verbs, adjectives, actions, subjects, places etc. The second type of web pages is the one that is usually used to show a list of results as a response to a search such as a list of books at amazon.com or any other web store. This type of web pages is typically generated by using a template and a set of data, see Figure 1. In this case, given a set of semi-structured web pages, we can infer one or more patterns that may be used to extract information from this type of web pages. A common objective of many information extractors is to discover the template used to generate these web pages, and use it to detect the data and extract it. The last type of web pages is the structured type. A structured web page is a web page that besides the presenting information in Html for human browsing, offers structured data that can be processed automatically by machines and are easily integrated into business processes. Our study focuses on information extraction from semi-structured web pages. As we mentioned before, given a set of semi-structured web pages, information extractors for this type of pages try to extract useful data which is the result returned from the data set before presenting it. Information Extractors apply many techniques in order to separate data from html tags and useless content, such as advertisements. These techniques usually try to detect one or more patterns to identify and extract interesting data from these web pages. Methods used by information extractors to learn patterns or to extract directly from web pages vary too much. Some information extractors consider web pages as a set of tokens and try to detect repeating patterns using string techniques (for example: [12] and [6]), others use DOM trees and try to detect repeating branches and children in these trees [5], some create and use statistical information to identify repeating zones and extract them directly [16] while others learns prefixes and suffixes for interesting data marked by user to apply them them over new web pages [15]. Besides classifying information extractors by input features, we can consider the the degree of automation for learning as another feature for classification. Information extractors usually learn a set of rules to use them later to extract information. We identified four types of learning algorithms: handcrafted, supervised, semi-supervised and unsupervised. Handcrafted algorithms are written manually for a special type of web pages and can only be used for similar pages having the same structure. Crafting such an information extractor is a hard task and any change in a web page may lead the information extractor to failure. Some information extraction algorithms need the user to Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 13 <!–- Sample #2 --> <html> <body> <b>Book name:</b> SPARQL in action <br/> <b>Reviews:</b> <br/> <ul> <li> <b>Reviewer:</b> Dan Smith <br/> <b>Rating:</b> 9 <br/>… </li> </ul> </body> </html> <!–- Sample #1 --> <html> <body> <b>Book name:</b> Ontologies <br/> <b>Reviews:</b> <br/> <ul> <li> <b>Reviewer:</b> John Doe <br/> <b>Rating:</b> 7 <br/>… </li> <li> <b>Reviewer:</b> Alan Wohl <br/> <b>Rating:</b> 8 <br/>… </li> </ul> </body> </html> <!--IE--> <html> <body> <b>Book name:</b> $2 <br/> <ul> (<li> <b>Reviewer:</b> $3 <br/> <b>Rating:</b> $4 <br/> <b>Text:</b> $5 </li>)+ </ul> </body> </html> Fig.2. RoadRunner: an unsupervised information extractor. mark the important data on some example web pages that are then used in the learning process. It is supervised if the user is required to mark the data to be extracted on sample pages; few authors distinguish between semi-supervised method in which few marking is required, and supervised, in which more marking is required. The last type contains the unsupervised information extractors, in this case, given one or more web pages, the learner automatically and without any user interference, identifies and extracts important information from these webs. An example of an unsupervised information extractor can be seen at figure ?? that induces extraction rules without and user interference. 3 Framework Here we present the first approximation to our information extraction framework. We identified several modules, each one has a determined task. Some tools are integrated into our framework and are used to prepare web pages for learning extraction rules or even for extracting information from input web pages. These tools are: a tokeniser and an annotating tool [13]. Our tokeniser allows the user to define the tokenisation necessary for his or her extraction algorithm, this gives flexibility to integrate new algorithms into our framework and to define new ones. The annotating tool can be used to mark entities inside a web page and assign them a class or a relation in a predefined ontology. User can configure these tools according to the case of use, this provides high flexibility for developing and using new extraction algorithms. Here we describe the the most important elements: –Preprocessor: Many information extraction algorithms preprocess web pages before learning or even before extracting information. We have identified two types of preprocessors: Transformer and Segmenter. A Transformer cleans Html code or performs part of speech tagging in case of free text information extractors, for this purpose HtmlTidy [17] is usually used. The segmenter depends on the extraction Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 14 Set TT TrainingSet Document +html: String Provenance -method: String -keywords: Map -url: URI +cachedURL: URI WebPage Segment provenance Mark -content: String -length: int +Compare(Mark): int {ordered} Token +content: String {ordered} {ordered} Locator -position: Xpointer -start{derived} -end{derived} OntologicalDescription provenance description locator TokenType tokenType DomTree -SubTrees: Set<DomTree> +DomTree(String) +getLeafs(): Set<DomTree> +getSubTreesByTag(String): Set<DomTree> +getSubTreesByLevel(int): Set<DomTree> +toString(): String DomTreeIterator +First(): DomTree +Next(): DomTree +Previous(): DomTree +Last(): DomTree +Actual(): Token TokenIterator +First(): Token +Next(): Token +Previous(): Token +Last(): Token +Actual(): Token MarkIterator +First(): Mark +Next(): Mark +Previous(): Mark +Last(): Mark +Actual(): Mark CharIterator +First(): Char +Next(): Char +Previous(): Char +Last(): Char +Actual(): Char creates document creates creates creates document document document description locator{derived} locator Fig.3. TrainingSet is composed of a set of Documents. algorithm. For example, some algorithms create clusters from web pages [14] as a first step, others separate DOM trees and remove unnecessary trees using [7]. –TrainingSet: This structure is the one that contains the web pages used to train information extractors creating extraction rules. See 3. A TrainingSet is a set of Documents which is the main class in this module. A Document is a web page or a segment of a web page. If an algorithm segments a web page before processing it, it creates new segments and adds them to the TrainingSet. The DOM tree of each document is obtained and the DOMTree structure is built. Before working with a Document, tokenisation should be performed using our previously mention tokeniser, creating and adding the sequence of tokens to each document. Besides tokenisation, the user should provide the Marks in the case the information extractor needs them to induce the extraction rules. These marks are added to the document creating instances of the class Mark whose OntologicalDescription is Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 15 Preprocessor Document Slot Automaton RuleSet Template InformationExtractor +process() +makeView(Document): View<<template>> +extract(Document, View): List<Slot><<template>> <<input>> <<output>> preprocessor{ordered} Ontologiser ontologiser 0..1 Fig.4. Information Extractor. assigned reading the marks ontology description provided by our annotation tool. Once a Document is marked and tokenised, the Learner Module can start working over the training set to discover extraction rules. The ontologicalDescription class is used to indicate where the ontology that describes an item is, and which class inside this ontology or even which property inside a class this item represents. The Provenance of a web page indicates the URI of an Html file, and the way used to reach and download this web page. The Locator indicates the position of an item inside a Document or inside an ontology, Xpointer is for this purpose. A segment has a Locator that indicates its start and end position in a given Document. The Locator also indicates which class or property inside an ontology provides semantics to a given mark. The TokenType is provided by our tokeniser and returns the type of the token depending on the it’s configuration file. Iterators are used in order to get documents of a training set, marks or tokens of a certain document or even DOM subtrees of a given Document. –Learner: Information extractors that learn rules use this module to deduce extraction rules. It provides to learners of extraction algorithms the capability of defining an ordered set of preprocessing steps before starting to extract from the input documents, and a set of classes with utilities such as a class to create clusters, generaliser or specialiser for regular expressions, also a String and a Tree aligner classes. Besides, this module contains template classes where predefined algorithms, such as Branch and Bound, are defined. Researchers should only give a body for some template methods in order to implement their proposals. The result of this module is an object of the class InformationExtractor, see Figure 4. An information extractor has an ordered set of preprocessors that should be executed over input documents before starting the information extraction, besides, it contains some template methods that should be defined by each extraction algorithm. Once extraction is performed, an information extractor creates slots that contain the extracted data and uses an ontologiser to identify and label extracted data. We have identified three types of information extractors: Those that work as an automaton such as [11] and [9], others identify local patterns for each element to be extracted, for example the two information extractores: [19] and [15]. The third Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 16 ResultSet SlotIterator +First(): Slot +Next(): Slot +Previous(): Slot +Last(): Slot +Actual(): Slot creates resultSet ResultSetBuilder +OpenResultSet(): ResultSet +openRecord(Record) +openslot(Slot) +addAttribute(Attribute) +closeResultSet() +closeRecord() +closeSlot() creates Slot Record Attribute -content: String slots Locator locator{derived} locator elements List TT Fig.5. ResultSet. type of extractors include those that identify a template for the complete web page such as [24] and [14]. In the case of information extractors that work as an automaton, the created InformationExtractor is an automaton with a set of states and transitions with rules. A transition is performed when its rule can be applied, in this case, a command can be executed. This command indicates the action that should be executed when data is extracted, for example slots containing extracted data can be created and saved. InformationExtractor that learns patterns to identify some elements in a web page create a set of rules. These rules are noniterating rules, since each one is executed over all the document, extracting the zones where it matches, for example, a pattern to detect book titles matches 3 times in a web page and returns three titles. The third type identifies a template and is executed once over the input document, it identifies the element that should be extracted and returns a set of slots. –WorkingSet: It contains a set of Documents, an InformationExtractor and a ResultSet. When an InformationExtractor is executed, the learned rules in a previous phase are executed over the set of Documents creating a ResultSet that is composed of a set of slots. To build a result set, ResultSetBuilder is used. Then, it uses the ontologiser to identify the classes and the relations between these slots, creating attributes and records then adding them to the ReultSet. At the end of the extraction, the ResultSet contains the extracted entities, each containing its attributes. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 17 4Conclusions and future work Although there is a great number of information extraction techniques, none of them is applicable for all cases of information extraction. Users interested in these techniques should make a deep study of all systems before considering which information extraction technique should be used for their purpose. This study is tedious and is a resource consuming task. Besides, once the user has decided which information extractor use, integrating this tool into his business applications needs more effort increasing the web information integration costs. Our framework contains common parts between the different information extraction algorithm, thus it supports reusability. New extraction algorithms can be implemented using our framework by reusing the developed modules and simply focusing on developing the main algorithm, so it reduces costs to develop new proposals. Testing and comparing information extractors are tasks that could be done using our framework since conditions are equal for all the tested algorithms. Using our information extraction framework, the effort used to compare different proposals is reduced since all algorithms are easily integrated, tested and compared between each others. Definitively, our framework can be considered as an important platform to reduce web information integration costs. Once the framework is completed, the second step is to create a taxonomy for classifying and comparing information extractors, but this time, more features will be comparable since the recall and precision will be calculated using our framework, under the same conditions. Also, the framework will be used to define new information extractors and compare them with the existing ones. References 1. Altigran S. da Silva Alberto H. F. Laender, Berthier Ribeiro-Neto. Debye - data extraction by example. Data Knowl. Eng., Vol. 40, 2001. 2. Altogran S. da Silva Juliana S. Teixeira Alberto H.F. Laender, Berthier A. Ribeiro-Neto. A brief survey of web data extraction tools. SIGMOD, 2002. 3. Casati F. Kuno H.-Machiraju V. Alonso, G. Web Services Concepts, Architectures and Applications. 2004. 4. Charles Schafer Andrew Carlson. Bootstrappiing information extraction from semistructured web pages. 2008. 5. MA David Karger Andrew Hogue. Thresher: automating the unwrapping of semantic content from the world wide web. ACM, 2005. 6. Hector Garcia-Molina Arvind Arasu. Extracting structured data from web pages. SIGMOD, 2003. 7. Yanhong Zhai Bing Liu, Robert Grossman. Mining data records in web pages. SIGKDD, 2003. 8. Moheb Ramzy Girgis Khaled F. Shaalan Chia-Hui Chang, Mohammed Kayed. A survey of web information extraction systems. IEEE, 2006. 9. Ming-Tzung Dung Chun-Nan Hsu. Generating finite-state transducers for semi-structured data extraction from the web. 1998. 10. Dawn G. Gregg. Exploring information extraction resilience. Journal of Universal Computer Science, 2008. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 18 6P. Jim´enez, J.L. Arjona, J.L. ´ Alvarez 4.1 Independiente del dominio Test T-Students pareado. Un test T-Students pareado es una f´ormula sencilla, que determina si dos nodos estad´ısticamente pueden considerarse iguales. Dos ramas dentro de un ´arbol, aunque sean completamente distintas para un experto humano, estad´ısticamente pueden ser iguales. Se trata de reducir la expansi´on de nodos a clases de equivalencia, de manera que, a cada clase pertenecieran todos aquellos nodos que estad´ısticamente parecen iguales. De esta forma, s´olo calculamos la ganancia de un ´unico nodo por clase. El n´umero de literales explorados se reduce al n´umero de clases encontradas. Asignaci´on de sem´antica a los predicados. La b´usqueda de una definici´on en FOIL es ciega, de modo que no tiene en cuenta la sem´antica de los predicados. Existen casos en los que no tendr´ıa sentido explorar ciertos literales. Por ejemplo, el literal previous(X, X) es correcto, sin embargo, para un observador humano est´a claro que no tiene inter´es ya que es imposible ser el antecesor de s´ı mismo. Podemos as´ı a˜nadir para cada predicado de soporte informaci´on sem´antica que permita prescindir de literales que, aunque son v´alidos, carecen de sentido pr´actico. Por ejemplo, podemos indicar que los predicados previous(X, Y ) y next(X, Y ), no tienen sentido cuando las variables X e Y son iguales. Exploraci´on de n predicados. Una de las formas m´as simples es ampliar la filosof´ıa greddy a la creaci´on de los nuevos predicados a evaluar. Nuestra propuesta es reducir este n´umero. Se establece as´ı una profundidad l´ımite p, un n´umero de caminos c, y un n´umero de predicados a explorar n. Se llevan de forma simult´anea los cmejores caminos de todos los posibles. De cada camino se obtienen los nnuevos predicados y de entre todos ellos se eligen los c−1 mejores y del resto de literales descartados se elige uno al azar para garantizar una cierta capacidad de exploraci´on. Estos predicados constituir´an los nuevos caminos a explorar. Una vez que se ha alcanzado una profundidad p(se han a˜nadido ppredicados) el algoritmo se centrar´a s´olo en el mejor de todos los caminos que se ha estado considerando. Selecci´on del primer predicado cuya ganancia supere un umbral. Esta propuesta se basa en generar todos los posibles nuevos predicados y seleccionar el primero con una ganancia que supere cierto umbral, dejando de evaluar el resto de predicados candidatos en ese nivel del ´arbol de exploraci´on. El problema de esta optimizaci´on es la generaci´on de reglas poco expresivas. No obstante, nuestro objetivo es desarrollar herramientas que hagan transparentes las reglas a los usuarios. Cat´alogo completo de predicados de soporte. Se trata de disponer de un conjunto ´util de predicados de soporte, catalogados por dominio, para ayudarnos Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 25 Optimizando FOIL para la Extracci´on de Informaci´on de la Web 7 a la hora de enfrentarnos a un nuevo sitio web. Adem´as, dando prioridad a predicados que tras un an´alisis previo, ya sea experimentalmente o proporcionados por un experto en el dominio se sepan que pueden alcanzar una mayor precisi´on si se incluyen en la regla. Determinar si una cadena de predicados est´a generada por azar. En Lerman [21], se usa el test de hip´otesis de Popoulis[22] donde mediante detecci´on de regularidades, es capaz de determinar si una secuencia de texto es fruto o no del azar. Ser´ıa interesante incorporar este test a FOIL, ya que as´ı podr´ıamos ser capaces de detectar, antes de evaluar, si la regla en construcci´on es aleatoria o no, y descartarla en caso afirmativo para centrarnos en otras m´as prometedoras. 4.2 Dependiente del dominio de Extracci´on de Informaci´on Uso de los predicados Left y Right. El objetivo de esta optimizaci´on es hacer uso de predicados que caractericen el contexto por la derecha y despu´es por la izquierda (o al rev´es) de la informaci´on a extraer. Se pretende explotar la estructura de las p´aginas Web. A este tipo de extractores de informaci´on se les denominan landmark [21]. Un ejemplo de este tipo de extractores son los de Kushmerick[8]. Por tanto, si la informaci´on se puede extraer a partir de su contexto, es francamente una buena idea darle prioridad a predicados que tienen como objetivo caracterizar el contexto por la derecha (p.e predicado next) y una vez que la ganancia no sea significativa, dar prioridad a predicados que tengan por objetivo fijar el contexto por la izquierda (p.e previous). Chequear si se pueden emplear este tipo de reglas landmark para extraer informaci´on de un sitio web, es tan f´acil como tomar n tokens por la izquierda y n tokens por la derecha de la informaci´on a extraer y aplicar un algoritmo tipo longest common subsequence 2 Priorizaci´on de Constantes. Durante la fase de etiquetado de p´aginas Webs que servir´an de entrenamiento al sistema, el experto humano puede observar patrones de tokens que aparecen a izquierda y derecha de la informaci´on a extraer. Si esto ocurre, podr´ıamos ordenar las clases de tokens en funci´on de la distancia en la que aparezcan de la informaci´on relevante, siendo prioritarias aquellas clases m´as cercanas a dicha informaci´on. De esta manera, en reglas en las que se hayan a˜nadido literales del tipo next(X, Y ) o previous(X, Y ) los literales m´as prometedores para evaluar en la siguiente iteraci´on son los predicados predefinidos del tipo Y=Csiendo Cun token de clase preferente. Incluso si el literal m´as prometedor fuera next(X, Y ), a˜nadir el siguiente m´as prometedor del tipo Y=Cen un solo paso. En el resto de predicados de soporte habr´ıa que estudiar su utilidad. 2http://en.wikipedia.org/wiki/Longest common subsequence problem/ Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 26 8P. Jim´enez, J.L. Arjona, J.L. ´ Alvarez Predicados que implementan modelos de caracter´ısticas de la informaci´on. Adem´as de las reglas de tipo landmark, disponemos de reglas de tipo content-based [21]. En este tipo de reglas se explota la estructura de la propia informaci´on a extraer. La idea es usar predicados de soporte que hagan referencia a las caracter´ısticas de la informaci´on a extraer. Las caracter´ısticas pueden clasificarse en dos grandes grupos, caracter´ısticas num´ericas o caracter´ısticas categ´oricas. Para el ejemplo de la figura 1 una posible regla obtenida por FOIL para extraer todos los coautores es: coauthor(X) : −a(X), digitDensity(X, 0) donde el predicado de soporte digitDensity se refiere a una caracter´ısticas num´erica de la informaci´on a extraer, para el ejemplo de la figura 1 puede generar una regla del tipo coauthor(X) : −a(X), nounP hrase(X) donde el predicado de soporte nounP hrase(X) se refiere a una caracter´ısticas ling¨uistica de la informaci´on a extraer. Las ventajas que ofrecen estas reglas es que son menos susceptibles a cambio que las landmark, el problema est´a en evaluar las caracter´ısticas, ya que supone un mayor coste computacional. Concatenar tokens next y previous. En FOIL, una variable en un predicado puede instanciarse a un token. Si en vez de instanciarse a un s´olo token puede instanciarse a un conjunto de ellos, estamos englobando varias iteraciones en una sola. Ser´ıa como seleccionar m´as de un literal candidato en una misma iteraci´on. Supongamos que los ejemplos positivos que quedan por cubrir son los coautores Krista Lagus ySamuel Kaski. Empezar´ıamos a generar una nueva regla para cubrir estos ejemplos. Una posible regla de salida que extrayera esta informaci´on sin extraer ning´un ejemplo negativo ser´ıa coauthor(X) : −next(X,0,0), next(0,0, Z), next(Z,0,0) Si permitimos la concatenaci´on de tokens, se podr´ıa generar una regla del tipo coauthor(X) : −next(X,0,0Z0,0) . Inducci´on de patrones. Inducir prefijos y sufijos de la informaci´on relevante, puede ser muy ´util cuando trabajamos con los predicados de soporte next y previous. Por ejemplo, si disponemos de la tupla ¡P, X, S¿ donde P es el prefijo de X inducido, S es el sufijo de X inducido y X es la informaci´on relevante, es apropiado dar asignar prioridad a predicados m´as espec´ıficos del tipo next(X, Y ), Y =So previous(X, Y ), Y =Po, de forma simplificada next(X, S) y previous(X, P ) respectivamente, porque aportar´an una ganancia m´as alta. Tanto P como S hacen referencia a un token o clase de tokens. Transferencia de predicados a expresiones regulares. Una vez tenemos las reglas de extracci´on, acceder a la informaci´on puede plantear importantes problemas de eficiencia. En el peor de los casos, tenemos que tokenizar toda la p´agina y a continuaci´on, para cada token, comprobar si se satisfacen todos los predicados de las reglas. En reglas de tipo landmark, este problema queda resuelto traduciendo la regla a una expresi´on regular, para una p´agina web, podr´ıamos Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 27 Optimizando FOIL para la Extracci´on de Informaci´on de la Web 9 identificar la informaci´on a extraer mediante una expresi´on xpath. Por ejemplo, si tenemos la regla coauthor(X) : −next(X, a), previous(X, b), previous(b, c) se podr´ıa traducir a la expresi´on regular: ∗cb$a∗, siendo * la clausura de kleene, y $ la informaci´on que queremos extraer. 5 Conclusiones En este art´ıculo hemos presentado 13 ideas originales que tienen por objetivo optimizar su eficiencia computacional de FOIL. Estas optimizaciones permiten la posibilidad de desarrollar APIs program´aticas para integrar aplicaciones Web (no desmantelables), abaratando los costes del desarrollo de extractores de informaci´on para soluciones de integraci´on. De entre las optimizaciones propuestas, 6 son independientes del dominio y 6 dependen del contexto de Extracci´on de Informaci´on de la Web. En el primer caso, las optimizaciones s´olo son aplicables al n´ucleo de FOIL, para reducir el n´umero de nodos a evaluar. Mientras que las optimizaciones del segundo tipo, van desde una adecuada definici´on de la base de conocimiento, hasta la reducci´on del n´umero de nodos a evaluar en el dominio de extracci´on de informaci´on y la adaptaci´on del conjunto de reglas inducidas de salida. Todas ellas, se pueden aplicar de forma independiente aunque nuestra propuesta es aplicarla de forma conjunta puesto que no son excluyentes. Para ello, estamos desarrollando un marco de trabajo te´orico que nos permita realizar un estudio experimental exhaustivo que determine, en funci´on de un problema, las optimizaciones a usar. References 1. Raghavan, S., Garcia-Molina, H.: Crawling the hidden web. In: VLDB ’01: Proceedings of the 27th International Conference on Very Large Data Bases, San Francisco, CA, USA, Morgan Kaufmann Publishers Inc. (2001) 129-138. 2. Pan, A., Raposo, J., ´ Alvarez, M., Carneiro, V., Bellas, F.: Automatically maintaining navigation sequences for querying semi-structured web sources. In: Data Knowl. Eng. 63(3) (2007) 795-810. 3. Lage, J.P., da Silva, A.S., Golgher, P.B., Laender, A.H.F.: Automatic generation of agents for collecting hidden web pages for data extraction. In: Data Knowl. Eng. 49(2) (2004) 177-196. 4. Kayed, M., Shaalan, K.F.: A survey of web information extraction systems. In: IEEE Trans. on Knowl. and Data Eng. 18(10) (2006) 1411-1428. 5. Arjona, J.L., Corchuelo, R., Ruiz, D., Toro, M.: From wrapping to knowledge. In: IEEE Trans. Knowl. Data Eng. 19(2) (2007) 310-323. 6. Kushmerick, N.: Regression testing for wrapper maintenance. In: AAAI ’99/IAAI’99: Proceedings of the sixteenth national conference on Artificial intelligence and the eleventh Innovative applications of artificial intelligence conference innovative applications of artificial intelligence, Menlo Park, CA, USA, American Association for Artificial Intelligence (1999) 74-79. 7. Kushmerick, N.: Wrapper verification. In: World Wide Web 3(2) (2000) 79-94. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 28 10 P. Jim´enez, J.L. Arjona, J.L. ´ Alvarez 8. Kushmerick N.: Wrapper induction: Efficiency and expressiveness In: Artif. Intell. 118, 15-68, (2000). 9. Hunt, E., Marin, J., Stone P.: Experements in induction. In: New York: Academic Press. (1996). 10. Quinlan J.: Induction of decision trees. In: Machine Learning, 1, 81-106. (1986). 11. Quinlan, J.: C4.5: Programs for Machine Learning. In: Morgan Kaufmann Publishers, 1993. 12. Breiman, L., Friedman, J., Oslhen, R., Stone, C.: Classification and regression tress. In: Belmont: Wadswroth, (1984). 13. Quinlan J.: Learning First-Order Defininitions of Functions. In: Journal of Artificial Intelligence Research, 5, 139-161, (1996). 14. Muggleton, S.: Inverse Entailment and Progol. In: New Generation Computing, Special issue on Inductive Logic Programming, 13, 1995 15. Craven,D.,DiPasquo, D., Freitag, D., McCallum, A., Mitchell, T., Nigam, K., Slattery, S.: Learning to Extract Symbolic Knowledge from the World Wide Web. In: Proceedings of the 15th National Conference on Artificial Intelligence, (2001). 16. Michalski, R., Mozetic, I., Hong, J., Lavrac, N.: The multipurpose incremental learning sustem AQ15 and its testing application to three medical domains. In: Proccedings of the Fith Nation Conference on Artificial Intelligence, Philadelphia, 1041-1045, (1986). 17. Crescenzi, V., Mecca, G., Merialdo, P.: RoadRunner: Towards Automatic Data Extraction from Large Web Sites. In: Proceedings of 27th International Conference on Very Large Data Bases, 109-118, (2001). 18. Zhai, Y.,Liu, B.: Web data extraction based on partial tree alignment. In: International World Wide Web Conference, 76-85, (2005). 19. Ma, L., Goharian, N., Chowdhury, A., Chung, M.: Extracting unstructured data from template generated web documents. In: Conference on Information and Knowledge Management, 213-215, (2003). 20. Muslea I., Minton, S., Knoblock, C.: Knoblock: Hierarchical Wrapper Induction for Semistructured Information Sources In: Journal of Autonomous Agents and Multi- Agent Systems 4 (1/2), 93-114, (2001). 21. Lerman, K., Minton, S. Knoblock, C.: Wrapper Maintenance: A Machine Learning Approach. In: Journal of Artificial Intelligence Research, 2002. 22. Papoulis, A.: Probability and Statistics. In: Prentice Hall, Englewood Cliffs, NJ, (1990). 23. Mitchell, T.: Machine Learning. In: McGraw Hill, 1997. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 29 Mejoras en la recuperaci´on web combinando campos Carlos G. Figuerola, Jos´e Luis Alonso Berrocal, y Angel Zazo Rodr´ıguez Grupo de Investigaci´on REINA, Universidad de Salamanca {figue, berrocal, zazo}@usal.es Resumen. Este art´ıculo describe algunas de las actividades del grupo de investigaci´on REINA en torno a la recuperaci´on de informaci´on web. Estas actividades se han centrado en probar la capacidad de recuperaci´on que puede esperarse de diversos elementos informativos presentes en las p´aginas web, adem´as del texto que el usuario visualiza normalmente en su navegador. Nuestro objetivo ha sido probar estrategias pre-recuperaci´on de mezclar o combinar esos campos o elementos de informaci´on. Combinar t´erminos de diversa procedencia en un ´unico ´ındice puede conseguirse, en sistemas basados en el modelo del espacio vectorial, operando sobre la fecuencia del t´ermino en el documento, si se aplica un esquema de pesado basado en tf ×idf. El campo BODY es, obviamente, el m´as potente desde el punto de vista de la recuperaci´on; pero los ANCHORs de los backlinks que reciben las p´aginas indizadas a˜naden una mejora considerable a los resultados de la recuperaci´on. El contenido de las etiquetas META, sin embargo, contribuyen poco a la mejora en la recuperaci´on. Palabras clave: Recuperaci´on de informaci´on, recuperaci´on web, modelo vectorial 1 Introducci´on Este art´ıculo describe los trabajos efectuados por el grupo de Investigaci´on REINA en torno a la posible mejora de los resultados en la recuperaci´on de p´aginas web en base a la consideraci´on de diversos campos o elementos de dichas p´aginas. La colecci´on de documentos utilizada como base ha sido la conocida como EuroGov, utilizada ampliamente en trabajos experimentales de este tipo [10]. En realidad, nuestros trabajos han utilizado la parte de documentos que est´an en castellano; tanto los que pertencen al dominio .es, como los que, perteneciendo a otros dominios diferentes, est´an tambien en esta lengua. De otro lado, muchos documentos pertenecientes al dominio .es est´an en otras lenguas. Adem´as de las otras lenguas que tambi´en se hablan en Espa˜na (catal´an, euskera, gallego), muchas de las p´aginas tienen versiones o traduciones internacionales; especialmente en ingl´es, pero tambi´en en otras como franc´es o alem´an. Adicionalmente, y por parecidas razones, p´aginas pertencientes a otros dominios de EuroGov tambi´es estaban en castellano, por lo que se decidi´o explorar la colecci´on entera recolectando todas las p´aginas cuyo idioma fuera el castellano. Lamentablemente, las cabeceras de las p´aginas web ofrecen informaci´on muy poco fiable; tanto sobre el idioma de las mismas como sobre otras cosas. En muchas ocasiones esas cabeceras est´an vac´ıas; mientras que en otros tienen contenidos que no se corresponden con la realidad. As´ı pues, tuvimos que recurrir a un detector de lenguaje para seleccionar las p´aginas en castellano existentes en la colecci´on EuroGov. El detector utilizado es TextCat [7], un programa basado en la construcci´on de patrones de uso de n-gramas para cada lengua contemplada; y la posterior categorizaci´on del texto cuya lengua se desea averiguar [2]. Por lo que se refiere a las consultas, se utilizaron las elaboradas en castellano durante las campa˜nas CLEF 2005 y 2006 [11], junto con los correspondientes juicios de relevancia. Este art´ıculo est´a organizado de la siguiente manera: en la pr´oxima secci´on se describe el enfoque adoptado para abordar el problema; en la secci´on siguiente se exponen los problemas Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 30 y las opciones adoptadas en lo que se refiere a an´alisis l´exico y extracci´on de t´erminos de las p´aginas. A continuaci´on, se discute acerca de los campos o elementos de informaci´on ´utiles en la indizaci´on y recuperaci´on. M´as adelante se muestran los experimentos llevados a cabo y sus resultados. Finalmente, se extraen unas conclusiones. 2 Nuestro enfoque La estrategia b´asica seguida es: primero, encontrar las p´aginas m´as relevantes para cada consulta y, de acuerdo con el tipo de consulta, reordenar la lista de los documentos m´as relevantes recuperados. As´ı, nuestro trabajo tiene dos partes fundamentales: encontrar p´aginas relevantes y despu´es ordenar de una forma ´util esas p´aginas. La tarea de recuperaci´on de las p´aginas relevantes para una consulta determinada puede abordarse mediante un sistema convencional de indizaci´on y recuperaci´on, como los basados en el modelo del espacio vectorial [9]. Sin embargo, en una p´agina web hay, adem´as del texto que el usuario ve en la ventana de su navegador, otros elementos informativos que pueden resultar interesantes desde el punto de vista de la recuperaci´on. Incluso dentro del propio texto podemos encontrar ciertas estructuras que pueden ayudar, junto con esos otros elementos informativos, a mejorar los resultados de la recuperaci´on. Por ejemplo, algunos de esos otros lementos mencionados son el campo TITLE, algunas etiquetas META, los anclas de los backlinks, etc. Dentro del campo body, que es lo que se visualiza en la ventana del navegador, podemos diferenciar partes que usan diferentes tipograf´ıas, por ejemplo. As´ı, tenemos diferentes fuentes de informaci´on que podemos fusionar. En este sentido, se han propuesto dos estrategias b´asicas de fusi´on: fusi´on o combinaci´on prerecuperaci´on y post-recuperaci´on [1], [6]. Ambas estrategias han sido probadas; la estrategia post-recuperaci´on consisti´o en construir un ´ındice para cada elemento de informaci´on a combinar. Cuando hay que resolver una consulta, ´esta es ejecutada contra cada uno de los´ındices constru´ıdos; los resultados obtenidos con cada ´ındice son fusionados despu´es en una ´unica lista de documentos recuperados. Tambi´en hemos probado la estrategia pre-recuperaci´on, que se ha concretado el la elaboraci´on de un ´unico ´ındice con los t´erminos de todos los elementos o campos contemplados; pero pesado de manera diferente. Una vez constru´ıdo este ´unico ´ındice, las consultas son ejecutadas normalmente contra ´el. Naturalmente, en la elaboraci´on de este ´unico ´ındice podemos buscar dar m´as o menos valor a un t´ermino en funci´on de que aparezca en un campo o en otro. Esto nos permite utilizar una combinaci´on que, bien afinada, deber´ıa proporcionar buenos resultados en la recuperaci´on. La aplicaci´on de diferente peso a los diferentes componentes de la mezcla, en nuestro caso, es f´acil. Para la indizaci´on y recuperaci´on utilizamos nuestro software Karpanta [4], basado en el conocido modelo vectorial, y, en consecuencia, no tenemos m´as que operar sobre la frecuencia de cada t´ermino en cada uno de los componentes de la combinaci´on. En este caso hemols aplicado un esquema de pesado ATU (slope=0.2) [12], pero la idea es similar para cualquier esquema de pesado basado en tf ×idf. Podemos aplicar un multiplicador a tf en funci´on del campo en que aparezca el t´ermino, de manera que haga aumentar o disminuir el peso de dicho t´ermino, sin dejar de considerar la frecuencia del t´ermino y el IDF . 2.1 An´alisis l´exico y extracci´on de t´erminos La primera opreaci´on, previa a cualquier otra, es la conversi´on de las p´aginas web a texto plano. Esto tambi´en era necesario para detectar la lengua de cada p´agina, dado que se decici´o trabajar s´olo con las que estaban en castellano.La obtenci´on del texto plano no es Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 31 trivial, y no est´a exenta de problemas. Como se ha comentado antes, no se puede confiar que en que se sigan los est´andares en todos los casos; ni siquiera es posible asegurar que el contenido sea HTML, aunque el documento comience con las etiquetas apropiadas. En algunas ocasiones podemos nos podemos encontrar directamento con c´odigo binario, PDFs y similares inmediatamente despu´es de un <HTML>. Con las etiquetas META sucede lo mismo; incluso cuando est´an presentes, no siempre ofrecen informaci´on correcta. De hecho, muchas p´aginas ni siquiera contienen texto; as´ı que lo primero es determinar el tipo de contenido. El viejo y bien conocido comando file, bien afinado, puede ayudar a determinar el contenido real de cada p´agina. Adicionalmente, nos informar´a sobre otra cuesti´on importante: el sistema de codificaci´on de caracteres utilizado. Para p´aginas en castellano, lo habitual es ISO 8859 oUTF-8; es necesario conocer esta informaci´on para tratar adecuadamente los caracteres especiales. La conversi´on a texto plano, cuando el documento parece ser realmente HTML, la efectuamos con w3m. Hay otros conversores, pero despu´es de varias pruebas los mejores resultados parecen ser los de w3m. Una vez obtenido el texto plano, podemos determinar el idioma mediante TexCat. Seleccionados los documentos en castellano, es preciso extraer t´erminos y normalizarlos en alguna manera. B´asicamente, los caracteres son convertidos a min´usculas, los acentos son eliminados, al igual que n´umeros, signos ortogr´aficos y similares. Se eliminan tambi´en palabras vac´ıas, de acuerdo con una lista est´andar para el castellano; y los dem´as t´erminos se pasan a trav´es de un s-stemmer mejorado [5]. 2.2 Campos utilizados Son varios los elementos o fuentes de informaci´on que podemos considerar en una p´agina web. La base es el campo BODY, obviamente, pero adem´as podemos usar el campo TITLE, que parece claramente descriptivo, al igual que varias etiquetas META que habitualmente son utilizadas para estos prop´ositos, en especial META content="Description" and META content="Keywords". Sin embargo, como ya hemops indicado en otro lugar ([3]), estos campos no est´an presentes de una manera uniforme en todas las p´aginas. Muchas no los contienen y otros tienen valores META generados de manera autom´atica por los programas que han producido esas p´aginas web. En otros casos, aunque los valores sean asignados de manera manual por los autores de las p´aginas, resultan poco operativos. Adicionalmente, podemos pensar que t´erminos que aparecen con tipograf´ıa resaltada pueden ser m´as representativos. Las etiquetas o campos H1, H2, etc. son un ejemplo. Desgraciadamente, el uso de estas etiquetas tampoco es uniforme, y ha evolucionado hacia la definici´on de fuentes y tama˜nos espec´ıficos de letra, m´as complejos de procesar. Otro elemento importante es el de los anclas de los backlinks, o enlaces desde otros lugares a la p´agina en cuesti´on. De manera m´as o menos breve, estos anclas describen la p´agina con la que conectan; esta descripci´on es importante, porque est´a hecha por alguien diferente del autor de la p´agina que queremos indizar. Podemos pensar que esta descripci´on a˜nade t´erminos distintos de los usados en la propia p´agina. No obstante, muchos de estos anclas pueden hacer referencia a partes muy concretas de la p´agina apuntada; igualmente, hay p´aginas con muchos backlinks y anclas y otras con pocos o ninguno. Y, en cualquier caso, tenemos el problema de obtener esos anclas. En nuestro caso, hemos procesado la totalidad de la colecci´on EuroGov para obtener todos los enlaces y sus correspondientes anclas que apuntan hacia p´aginas en castellano. Es evidente que fuera del la colecci´on EuroGov hay m´as enlaces que apuntan hacia dichas p´aginas, pero no tenemos forma de obtenerlos. Finalmente, hemos construido ´ındices con los siguientes elementos: BODY,TITLE,META content=Title,META content=description,META content=keywords,H1,H2,ANCHORS. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 32 3 Experimentos Apoy´andonos en las estimaciones de relevancia que forman parte de la colecci´on de documentos, hemos efectuados diversas pruebas con varias combinaciones de elementos o campos en distintas proporciones. Hemos elegido como l´ınea base para comparaciones los resultados con un ´ındice formado exclusivamente por los t´erminos que aparecen en el campo BODY. BODY(fd=1) ANCHOR(fd=1) TITLE (fd=1.5) META-DESC (fd=1.5) META-TITLE (fd=1) META-KEY (fd=0.5) H1 (fd=0.8) H2 (fd=0.8) Tabla 1. Combinaci´on ganadora Fig. 1. Resultados con campo BODY y con Combinaci´on Ganadora Como era de esperar, el uso de cualquiera de esos elmentos en adici´on al campo BODY mejora los resultados de la recuperaci´on. Pero algunos de esos elementos lo hacen de forma notable y otros no tanto. Tambi´en hemos efectuado pruebas con´ındices compuestos por uno solo de cada uno de los campos. Esto nos permite observar la utilidad, desde el punto de vista de la recuperaci´on, de cada uno de esos campos. El gr´afico muesta los resultados; cada curva representa los obtenidos tras ejecutar la bater´ıa de consultas contra un ´ındice elaborado con los t´erminos de cada campo o elemento de informaci´on (fd = 1). Cada curva se refiere a uno solo de esos campos, sin utilizar los t´erminso del BODY. Los campos H1 yH2 no aparecen en el Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 33 gr´afico porque producen resultados extremadamente pobres. Es evidente que muchas p´aginas carecen de uno o varios de estos campos, raz´on por la cual nunca podr´an ser recuperados a partir de esos campos; pero es una de verificar por separado la capacidad de recuperaci´on de esos campos. Como era esperable, cada campo por separado produce peores resultados que BODY, lo cual es normal, pues este campo contiene la parte visualizable de la p´agina web. Pero tras el campo BODY el campo que parece m´as interesante desde el punto de vista de la recuperaci´on es el de los ANCHORs de los backlinks, aunque en muchos casos tales anclas sean muy breves. Pero parece que, como se ha dicho, las descripciones que otros hacen de una p´agina son muy eficaces para su recuperaci´on. Le sigue a corta distancia el campo TITLE, algo previsible. Sin embargo, los campos basados en etiquetas META ofrecen resultados bastante pobres, a bastante distancia de ANCHOR yTITLE; y eso a pesar de que son campos concebidos espec´ıficamente para la recuperaci´on. Aunque hay poca diferencia entre los resultados de los tres META observados (title,description ykeywords) es ´este ´ultimo, curiosamente, el que peores resultados produce de los tres. Fig. 2. Aportaci´on de campos individuales 4 Conclusiones Hemos descrito algunos de los experimentos realizados sobre la recuperaci´on de p´aginas web a partir de determinados elementos. El uso de tales campos o elementos de informaci´on, adem´as del texto dela zona BODY de las p´aginas web permite mejorar los resultados de la recuperaci´on de informaci´on. Una forma de hacerlo es elaborar un ´unico ´ındice con los t´erminos que aparecen en esos campos, junto con los que aparecen el el BODY; pero pes´andolos de manera diferente, ajustable de forma emp´ırica. De todos esos campos, parece que el m´as eficaz es el de los ANCHORS de los backlinks que recibe cada p´agina. El campo TITLE tambi´en contribuye de manera importante a la mejora Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 34 not processed. Whenever a form is detected, it is submitted again, and process continues recursively. If a large number of links are detected, it is considered a hub page, and a further analysis is needed to select which links will be followed. Links are grouped by their URL similarity, and only one link from each group is followed to check if it leads to a relevant page. This proposal is semi-supervised, since the process is automated, but the user has to provide a sample detail page, aside from filling in the parameter values for every form submission. This navigator can only reach a small number of possible results, for two reasons: it only keeps navigation patterns leading to the largest number of relevant pages, and besides, links leading to other hub pages are not considered, only links to detail pages, so only relevant pages referenced in the first hub page are retrieved. This navigator has to be combined with an iterator in order to retrieve all possible results. Another question to bear in mind is that navigation systems are ad-hoc. If the site changes its URL nomenclature, the system has to be trained again, thus requiring user intervention, to update navigation patterns. This proposal has some technical problems to be solved, namely, the heuristic for the treatment of form pages can lead to an infinite loop, in cases in which the server includes the original form in every response page. It does not support form submission using the POST method. Finally, it does not support web sites that keep user session information. [8] is another automated navigator. It is similar to the former: it relies on a structural-based clustering of pages, and it requires a sample relevant page. All pages are grouped in clusters, according to their structure, and links between pages are analysed in order to find relationships between clusters. Whenever a cluster has a high number of outgoing links to the cluster containing the sample, it is considered a hub cluster. This proposal is not designed to crawl pages behind forms, and therefore should be adapted in order to retrieve pages from the deep web. 3 Experimental Study In order to justify the need for an intelligent navigator, we analysed a sample set of real web pages, and calculated the percentage of relevant links they included. Sample pages were extracted from Alexa Web Directory1. Alexa is supported by a traditional crawler, which collects publicly available web pages, rank them and offer additional information about them, like traffic statistics, demographic distribution of page viewers, keywords used to find that page in search engines, and related links. The first ten sites from each category were chosen, excluding Adults and Reference categories. Sites without hubs were discarded too, as well as sites that required user session information, or that enclosed relevant information in iframes (due to some conflicts with the Selenium XPath API), as they are not useful for our purposes. For every web site, a query was issued in order to 1http://www.alexa.com/topsites Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 41 obtain aresponse hub page. XPath expressions for relevant links in these pages were extracted by hand, including those that lead from one paginated hub to the next one. We developed a Java application using Selenium Core Reference Library2, which automatically visited every page, calculated the number of relevant links defined by XPath expressions, as well as the total number of links in the page, and stored the page in a local repository. In order to analyse the 25% 50% 15% 10% < 10% relevant links Between 10% and 27,49 % relevant links Between 27,49 % and 47,52% relevant links > 47,52 % relevant links Fig. 2: Percentage Distribution results, we calculated the percentage of relevant links in every page, and the average percentage of relevant links per category. Figure 2 shows the percentage distribution we obtained with a sample set of 150 sites. Barely a 10% of the pages contained a percentage of relevant links higher than 47,52%. In fact, the quartile distribution was: (10,01%; 15,19%; 27,49%; 95,67%). The average percentage value of relevant links for all analysed pages was 22,35% with a standard deviation equal to 19,85. Figure 3 left shows the percentage of relevant links for every page in a random category (Arts). Figure 3 right shows the average percentage values by category. Values for all categories were similar, around 20%, except for Health category, which had the highest percentage value, with a 43%. These results confirm that average pages contain a high percentage of useless links, which should be avoided by the crawler in order to improve its efficiency. 4 Conclusions and Research Questions The main problem posed in this paper is the development of an intelligent navigation system for virtual integration within the Deep Web, as opposed to the blind navigation performed by most of the previous works. In this context, users specify their interests by means of queries, and information is retrieved from several 2http://seleniumhq.org/ Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 42 0 10 20 30 40 50 Arts Business Computers Games Health Home Kids and … News Recreation Regional Science Shopping Society Sports World % Average Relevant Links % Relevant Links 0 10 20 30 40 50 60 70 80 90 Category: Arts % Relevant Links Fig. 3: Experimental Results web applications. Response pages are analysed, navigating through their links and collecting only those pages that contain relevant information. In contrast, traditional crawlers follow every link and collect every possible page, wasting a lot of time and resources. In order to support our thesis, we presented an experimental study, in which we estimated the average percentage of relevant links included in every page. We came to the conclusion that most pages in our sample set have a low percentage of relevant links. As we mentioned before, virtual integration is an online process, hence information should be presented to the user in a reasonable response time. Therefore, these systems will indeed find benefits in the application of an intelligent navigator, which avoids visiting useless pages by following only relevant links, reducing the cost and improving the efficiency of traditional crawling systems. Summarising, these are some other research challenges concerning intelligent navigation: 1. Response pages have to be classified into the different roles that they play, in order to automatically deal with them. 2. Links in hub pages have to be classified before clicking on them, to identify those that lead to relevant pages. 3. Lazy link and web page classifiers work better in this context, i.e., classification model is built and updated progressively during the process. 4. Navigator should interact with the user as little as possible. Therefore, learning is unsupervised, or at least, very little supervised. Also, it should be as general as possible, not having to build an ad-hoc model for every site, but instead developing a general model that can adapt to most sites just by tuning some parameters. 5. Advanced post-filtering of hub pages is also a desirable feature. For example, when looking for products in an online store, a user may wish to retrieve only those products whose price lay within a certain range. This means that the navigator needs to be endowed with a lite extraction tool. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 43 6. It is necessary to create a standard data set to evaluate classification and navigation proposals. Most proposals so not use a well-known data set in their experiments; instead, they collect their own set of pages by issuing queries to a search engine, or using a blind crawler. As the experiments are performed on different sets of pages, the experimental results cannot be compared. There are some well known data sets of already classified pages available for this kind of experiments, e.g., the WebKB collection3, the Reuters-215784news collection or the TEL-8 query interfaces collection5. [35] reports an attempt to collect a standard data set. Unfortunately, these collections are outdated and updating them is a costly task. We argue that more effort on archiving needs to be done so that new proposals can be compared from an empirical point of view. References 1. C. C. Aggarwal et al. On the design of a learning crawler for topical resource discovery. ACM Trans. Inf. Syst., 19(3), 2001. 2. V. Anupam et al. Automating web navigation with the webvcr. Computer Networks, 33(1-6), 2000. 3. A. Arasu and H. Garcia-Molina. Extracting structured data from web pages. In SIGMOD Conference, 2003. 4. Z. Bar-Yossef and S. Rajagopalan. Template detection via data mining and its applications. In WWW, 2002. 5. L. Barbosa and J. Freire. Searching for hidden-web databases. In WebDB, 2005. 6. S. Batsakis et al. Improving the performance of focused web crawlers. Data & Knowledge Engineering, In Press, Corrected Proof, 2009. 7. R. Baumgartner et al. Deep web navigation in web data extraction. In CIMCA/IAWTIC, 2005. 8. L. Blanco et al. Efficiently locating collections of web pages to wrap. In WEBIST, 2005. 9. L. Blanco et al. Structure and semantics of data-intensiveweb pages: An experimental study on their relationships. J. UCS, 14(11), 2008. 10. J. Blythe et al. Information integration for the masses. J. UCS, 14(11), 2008. 11. J. Caverlee and L. Liu. Qa-pagelet: Data preparation techniques for large-scale data analysis of the deep web. IEEE Trans. Knowl. Data Eng., 17(9), 2005. 12. S. Chakrabarti et al. Automatic resource compilation by analyzing hyperlink structure and associated text. Computer Networks, 30(1-7), 1998. 13. S. Chakrabarti et al. Focused crawling: A new approach to topic-specific web resource discovery. Computer Networks, 31(11-16), 1999. 14. W. W. Cohen et al. Improving a page classifier with anchor extraction and link analysis. In NIPS, 2002. 15. V. Crescenzi et al. Roadrunner: Towards automatic data extraction from large web sites. In VLDB, 2001. 16. H. Davulcu et al. A layered architecture for querying dynamic web content. In SIGMOD Conference, 1999. 3http://www.cs.cmu.edu/afs/cs/project/theo-20/www/data/ 4http://www.daviddlewis.com/resources/testcollections/reuters21578/ 5http://metaquerier.cs.uiuc.edu/repository/datasets/tel-8/ Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 44 17. G. T. de Assis et al. Exploiting genre in focused crawling. In SPIRE, 2007. 18. D. de Castro Reis et al. Automatic web news extraction using tree edit distance. In WWW, 2004. 19. J. F¨urnkranz et al. Hyperlink ensembles: a case study in hypertext classification. Information Fusion, 3(4), 2002. 20. S. Grumbach and G. Mecca. In search of the lost schema. In ICDT, 1999. 21. A. Hotho et al. Ontology-based text document clustering. KI, 16(4), 2002. 22. J. P. Lage et al. Automatic generation of agents for collecting hidden web pages for data extraction. Data Knowl. Eng., 49(2), 2004. 23. S. W. Liddle et al. Extracting data behind web forms. In ER (Workshops), 2002. 24. J. Madhavan et al. Harnessing the deep web: Present and future. In CIDR, 2009. 25. A. Markov et al. The hybrid representation model for web document classification. Int. J. Intell. Syst., 23(6), 2008. 26. P. Montoto et al. A workflow language for web automation. J. UCS, 14(11), 2008. 27. S. Mukherjea et al. Discovering and analyzing world wide web collections. Knowl. Inf. Syst., 6(2), 2004. 28. A. Pan et al. Semi-automatic wrapper generation for commercial web sources. In Engineering Information Systems in the Internet Context, 2002. 29. G. Pant and P. Srinivasan. Learning to crawl: Comparing classification schemes. ACM Trans. Inf. Syst., 23(4), 2005. 30. G. Pant and P. Srinivasan. Link contexts in classifier-guided topical crawlers. IEEE Trans. Knowl. Data Eng., 18(1), 2006. 31. I. Partalas et al. Reinforcement learning with classifier selection for focused crawling. In ECAI, 2008. 32. J. M. Pierre et al. On the automated classification of web sites. CoRR, cs.IR/0102002, 2001. 33. S. Raghavan and H. Garcia-Molina. Crawling the hidden web. In VLDB, 2001. 34. A. Selamat and S. Omatu. Web page feature selection and classification using neural networks. Inf. Sci., 158, 2004. 35. M. Sinka and D. Corne. A large benchmark dataset for web document clustering. In Soft Computing Systems: Design, Management and Applications, Volume 87 of Frontiers in Artificial Intelligence and Applications. 2002. 36. M. L. A. Vidal et al. Structure-based crawling in the hidden web. J. UCS, 14(11), 2008. 37. K. Vieira et al. A fast and robust method for web page template detection and removal. In CIKM, 2006. 38. Y. Wang and T. Hornung. Deep web navigation by example. In BIS (Workshops), 2008. 39. H. Yu et al. Pebl: Web page classification without negative examples. IEEE Trans. Knowl. Data Eng., 16(1), 2004. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 45 Web avigation Automation in AJAX Websites Paula Montoto1, Alberto Pan1, Juan Raposo1, Fernando Bellas1 and Javier López1, 1 Department of Information and Communication Technologies, University of A Coruña Facultad de Informática, Campus de Elviña s/n 15071 A Coruña, Spain {pmontoto,apan,jrs,fbellas,jmato}@udc.es Abstract. Web automation applications are widely used for different purposes such as B2B integration or automated testing of web applications. One crucial part in web automation applications is to allow easily generating and reproducing navigation sequences. Previous proposals in the literature assumed a navigation model today turned obsolete by the new breed of AJAX-based websites. Although some open-source and commercial tools have also addressed the problem, they show significant limitations either in usability or their ability to deal with complex websites. In this paper, we propose a set of new techniques to deal with this problem. Keywords: Web automation, web integration, web wrappers. 1 Introduction Web automation applications are widely used for different purposes such as B2B integration, web mashups, automated testing of web applications or business watch. One crucial part in web automation applications is to allow easily generating and reproducing navigation sequences. We can distinguish two stages in this process: − Generation phase. In this stage, the user specifies the navigation sequence to reproduce. The most common approach, cf. [1,9], is using the ‘recorder’ metaphor: the user performs one example of the navigation sequence using a modified web browser, and the tool generates a specification which can be run by the execution component. − Execution phase. In this stage, the sequence generated in the previous stage and the input parameters are provided as input to an automatic navigation component which is able to reproduce the sequence. The automatic navigation component can be developed by using the APIs of popular browsers (e.g. [11]). Other systems [1] use simplified custom browsers. Most existing proposals assume a navigation model which is now obsolete: on one hand, the user actions that could be recorded were mainly restricted to clicking on elements and filling in form fields; on the other hand, it was assumed that almost every user action caused a request to the server for a new page. Nevertheless, this is not enough for dealing with modern AJAX-based websites. These sites can respond to a much wider set of user actions (mouse over, keyboard strokes, drag and drop…) and they respond to those actions executing scripting code that manipulates the page at will (for instance, by creating new elements on the fly). Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 46 In this paper, we propose a set of new techniques to build an automatic web navigation system able to deal with all this complexity. In the generation phase, we also use the ‘recorder’ metaphor, but substantially modified to support recording a wider range of events; we also present new methods for identifying the elements participating in a navigation sequence in a change-resilient manner. In the execution phase, we use the APIs of commercial web browsers to implement the automatic web navigation components (the techniques proposed for the recording phase have been implemented using Microsoft Internet Explorer (MSIE) and the execution phase has been implemented using both MSIE and Firefox). We take this option because the approach of creating a custom browser supporting technologies such as scripting code and AJAX requests is very vulnerable to small implementation differences that can make a web page to behave differently. In the execution phase, we also introduce a method to detect when the effects caused by a user action have finished. This is needed because one navigation step may require the effects of the previous ones to be completed before being executed. 2 Models In this section we describe the models we use to characterize the components used for automated browsing. The main model we rely on is DOM Level 3 Events Model [2]. This model describes how browsers respond to user-performed actions on an HTML page currently loaded in the browser. Although the degree of implementation of this standard by real browsers is variable, the key assumptions our techniques rely on are verified in the most popular browsers (MSIE and Firefox). 2.1 DOM Level 3 Events Model In the DOM Level 3 Events Model, a page is modelled as a tree. Each node in the tree can receive events produced (directly or indirectly) by the user actions. Event types exist for actions such as clicking on an element (click), moving the mouse cursor over it (mouseover) or specifying the value of a form field (change), to name a few. Each node can register a set of event listeners for each event type. A listener executes arbitrary code (typically written in a script language such as Javascript). Listeners have the entire page tree accessible and can perform actions such as modifying existing nodes, removing them, creating new ones or even launching new events. The event processing lifecycle can be summarized as follows: The event is dispatched following a path from the root of the tree to the target node. It can be handled locally at the target node or at any target's ancestors in the tree. The event dispatching (also called event propagation) occurs in three phases and in the following order: capture (the event is dispatched to the target’s ancestors from the root of the tree to the direct parent of the target node), target (the event is dispatched to the target node) and bubbling (the event is dispatched to the target's ancestors from the direct parent of the target node to the root of the tree). The listeners in a node can register to either the capture or the bubbling phase. In the target phase, the events registered for the capture phase are executed before the events executed for the Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 47 bubbling phase. This lifecycle is a compromise between the approaches historically used in major browsers (Microsoft IE using bubbling and Netscape using capture). The order of execution between the listeners associated to an event type in the same node is registration order. The event model is re-entrant, meaning that the execution of a listener can generate new events. Those new events will be processed synchronously; that is, if li, li+1 are two listeners registered to a certain event type in a given node in consecutive order, then all events caused by li execution will be processed (and, therefore, their associated listeners executed) before li+1 is executed. Fig. 1. Listeners Execution Example Example 1: Fig. 1 shows an excerpt of a DOM tree and the listeners registered to the event types e1 and e2. The listeners in each node for each event type are listed in registration order (the listeners registered for the capture phase appear as lcxyz and the ones registered for the bubbling phase appear as lbxyz). The figure also shows what listeners and in which order would be executed in the case of receiving the event-type e1 over the node n3, assuming that the listener on the capture phase lc313 causes the event-type e2 to be executed over the node n4. DOM Level 3 Events Model provides an API for programmatically registering new listeners and generating new events. Nevertheless, it does not provide an introspection API to obtain the listeners registered for an event type in a certain node. As we will see in section 3.1, this will have implications in the recording process in our system. 2.2 Asynchronous Functions and Scripts Execution Model In this section we describe the model we use to represent how the browser executes the scripting code of the listeners associated to an event. This model is verified by the major commercial browsers. The script engine used by the browser executes scripts sequentially in single-thread mode. The scripts are added to an execution queue in invocation order; the script engine works by sequentially executing the scripts in the order specified by the queue. When an event is triggered, the browser obtains the listeners that will be triggered by the event and invokes its associated scripts, causing them to be added to the execution queue. Once all the scripts have been added, execution begins and the listeners are executed sequentially. n1 n2 n3 n4 e 1 {lc 31 1 , lc 31 2 , l c 3 13 } {lb 311 , lb 312 } e 1 {lc 21 1 } {lb 21 1 } e 1 {lc 11 1 , lc 11 2 } {lb 11 1 } e 2 {lc 421 , lc 422 } {lb 421 , lb 422 } function lc 313 () { n 4 .fireEvent("e 2 ") } {lc 111 , lc 112 , lc 211 , lc 311 , lc 312 , lc 313 , {lc 421 , lc 422 , lb 421 , lb 422 }, lb 311 , lb 312 lb 211 , lb 111 } Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 48 The complexity of this model is slightly increased because the code of a listener can execute asynchronous functions. An asynchronous function executes an action in a non-blocking form. The action will run on the background and a callback function provided as parameter in the asynchronous function invocation will be called when the action finishes. The most popular type of asynchronous call is the so-called AJAX requests. An AJAX request is implemented by a script function (i.e. in Javascript, a commonly used one is XMLHTTPRequest) that launches an HTTP request in the background. When the server response is received, the callback function is invoked to process it. Other popular asynchronous calls establish timers and the callback function is invoked when the timer expires. In this group, we find the Javascript functions setTimeout(ms) and setInterval(ms). Both have associated cancellation functions. It is important to notice that, from the described execution model, it is inferred the following property: Property 1: The callback functions of the asynchronous calls launched by the listeners of an event will never be executed until all other scripts associated to that event have finished. The explanation for this property is direct from the above points: all the listeners associated to an event are added to the execution queue first, and those listeners are the ones invoking the asynchronous functions; therefore, the callback functions will always be positioned after them in the execution queue even if the background action executed by the asynchronous call is instantaneous. 3 Description of the Solution 3.1 Recording User Events The generation phase has the goal of recording a sequence of actions performed by the user to allow reproducing them later during the execution phase. A user action (e.g. a click on a button) causes a list of events to be issued to the target node, triggering the invocation of the listeners registered for them in the node and its ancestors, according to the execution model described in the previous section. Notice that each user action usually generates several events. For instance, the events generated when the user clicks on a button include, among others, the mouseover event besides of the click event, since in order to click on an element it is previously required to place the mouse over it. Recording a user action consists in detecting which events are issued, and in locating the target node of those events. In previous proposals, cf. [1,9], the user can record a navigation sequence by performing it in the browser in the same way as any other navigation. The method used to detect the user actions in these systems is typically as follows: the recording tool registers its own listeners for the most common events involved in navigations (mainly clicks and the events involved in filling in form fields) in anchors and formrelated tags. This way, when a user action produces one of the monitored event-types e on one of the monitored nodes n, the listener for e in n is invoked, implicitly identifying the information to be recorded. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 49 Nevertheless, the modern AJAX-based websites can respond to a much wider set of user actions (e.g. placing the mouse over an element, producing keyboard strokes, drag and drop…); in addition, virtually any HTML element, and not only traditional navigation-related elements, can respond to user actions: tables, images, texts, etc. Extending the mentioned recording process to support AJAX-based sites would involve registering listeners for every event in every node of the DOM tree (or, alternatively, registering listeners for every event in the root node of the page, since the events execution model ensures that all events reach to the root). Registering listeners for every event has the important drawback that it would “flood” the system by recording unnecessary events (e.g. simply moving the mouse over the page would generate hundreds of mouseover and mouseout events); recall that, as mentioned in section 2, it is not possible to introspect what events a node has registered a listener for; therefore, it is not possible to use the approach of registering a listener for an event-type e only in the nodes that already have other listeners for e. Therefore, we need a new method for recording user actions. Our proposal is letting the user explicitly specify each action by placing the mouse over the target element, clicking on the right mouse button, and choosing the desired action in the contextual menu (see Fig. 2). If the desired action involves providing input data into an input element or a selection list, then a pop-up window opens allowing the user to specify the desired value (see Fig. 2). Although in this method the navigation recording process is different from normal browsing, it is still fast and intuitive: the user simply changes the left mouse button for the right mouse button and fills in the value of certain form fields in a pop-up window instead of in the field itself. This way, we do not need to add any new listener: we know the target element by capturing the coordinates where the mouse pointer is placed when the action is specified, and using browser APIs to know what node the coordinates correspond to. The events recorded are implicitly identified by the selected action. Fig. 2. Recording Method Our prototype implementation includes actions such as click, mouseover, mouseout, selectOption (selecting values on a selection list), setText (providing input data into an element), drag and drop. Since each user action actually generates more than one event, each action has associated the list of events that it causes: for instance, Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 50 La utilizaci´on compartida de un conjunto de conceptos con sem´antica bien definida (conceptos que se representan mediante un conjunto de t´erminos representantes) ser´ıa la situaci´on ideal –reutilizaci´on de las mismas herramientas conceptuales–. Pero, como hemos dicho, no es la situaci´on habitual, ya que en muchos casos cada sistema utiliza sus propios conceptos. La integraci´on sem´antica es la encargada de paliar este problema. La Web Sem´antica no ser´ıa tal si no se cumple el objetivo de que los datos sean legibles y comprensibles por los agentes software [2], para lo cual son necesarios est´andares que permitan la representaci´on de informaci´on en formatos interoperables. Con este fin surgen los distintos est´andares de representaci´on, comenzando con XML, y siguiendo con los que se apoyan en ´el. RDF permite representar metadatos. RDF Schema a˜nade la posibilidad de representar el vocabulario utilizado en grafos RDF y relacionarlo mediante estructuras clasificatorias sencillas como taxonom´ıas. OWL aporta el vocabulario est´andar para representar ontolog´ıas. SKOS es un ”modelo de datos dise˜nado para compartir sistemas de organizaci´on de conocimiento en la Web”[17]. SKOS se puede implementar sobre RDF, utilizarse aisladamente, o combinarlo con OWL [17]. En la versi´on b´asica de SKOS, los recursos conceptuales, esto es, los conceptos, se identifican mediante URI, cada concepto tiene al menos un t´ermino que lo representa, los conceptos se relacionan entre si, creando jerarqu´ıas de conceptos, y se agregan bajo estructuras denominadas esquemas de conceptos (concept schemes). En su versi´on avanzada se introduce la posibilidad de agrupar conceptos que est´an en distintos esquemas de conceptos en colecciones (collections), que pueden estar o no ordenadas. Tambi´en en el marco de la Web Sem´antica, se proporcionan los lenguajes de consulta est´andar que deben permitir recuperar la informaci´on modelada utilizando estos est´andares de representaci´on. XQuery [4] permite consultar datos XML, y SPARQL [15] es un lenguaje de consulta para RDF que se estabiliz´o como recomendaci´on del W3C a principios de 2008. Parece claro en este contexto que la integraci´on en el nivel de conocimiento debe venir de la mano de la utilizaci´on combinada de estos instrumentos (herramientas conceptuales y est´andares de representaci´on), e incluso que su uso deber´ıa ser suficiente para garantizarla. Sin embargo, esta ´ultima afirmaci´on deber´ıa ser m´as bien una pregunta. Una pregunta cuya respuesta vamos a analizar en un dominio de aplicaci´on con el que venimos trabajando desde hace tiempo [9]: los sistemas de informaci´on jur´ıdica. 2. Representaci´on de conocimiento en los sistemas de informaci´on jur´ıdica mediante tesauros y XML En la manipulaci´on de informaci´on jur´ıdica el uso de XML como el est´andar m´as adecuado para representar la informaci´on se ha generalizado de tal modo que es imposible hablar de sistemas de informaci´on jur´ıdica sin pensar en la utilizaci´on de XML [1,3]. Nuestro trabajo viene siguiendo esta filosof´ıa desde hace tiempo [10]. Dise˜namos esquemas de representaci´on de los textos jur´ıdicos Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 57 y sus metadatos y utilizamos los est´andares asociados a XML para representarlos y acceder a ellos desde diversas aplicaciones [9]. Una interesante utilidad para los usuarios de estos sistemas es la posibilidad de anotar los textos, o los elementos de informaci´on representativos (elementos de estructura en nuestro caso), con comentarios sobre su campo de aplicaci´on, tema o temas con los que est´a relacionado y otras observaciones. En el caso de herramientas docentes, como algunas de nuestras aplicaciones [13], esto puede servir para que el profesor indique a los alumnos con qu´e tema o temas de la materia deber´ıa relacionar el documento que est´a analizando. Tambi´en est´a, por supuesto, la posibilidad m´as tradicional de clasificar los documentos en funci´on de materia o materias, de modo que despu´es se permitan b´usquedas de documentos relacionados con una determinada materia. Esta extensi´on a trav´es de anotaciones es la que motiva nuestra b´usqueda de una herramienta donde est´en representados los conceptos que utilizar´an nuestros usuarios, as´ı como nuestra indagaci´on en los est´andares vistos en la secci´on 1 para representar y manipular convenientemente este conocimiento. La primera cuesti´on que nos planteamos fue: ¿existe una herramienta de representaci´on de conocimiento que podamos reutilizar o necesitaremos crear nuestra propia herramienta conceptual? En nuestro caso decidimos utilizar el tesauro Eurovoc [12], mantenido por la Oficina de Publicaciones de las Comunidades Europeas3. Las ventajas de este tesauro son varias. En primer lugar, el hecho de que sea el tesauro oficial que la Oficina de Publicaciones utiliza en sus sistemas de informaci´on hace de ´el el m´as robusto y est´andar de los tesauros que se usan en el campo de la informaci´on jur´ıdica. Los recursos disponibles para su mantenimiento, entre los cuales es esencial la actualizaci´on terminol´ogica que conlleva la inclusi´on y eliminaci´on de nuevos t´erminos en versiones sucesivas, garantizan que Eurovoc es un tesauro ’vivo’, que no queda obsoleto con el paso del tiempo. Su utilizaci´on por parte de un buen n´umero de instituciones oficiales en los distintos pa´ıses de la Uni´on Europea, como el Senado en Espa˜na [5], induce su utilizaci´on en cuantos sistemas buscan interoperabilidad con cualquiera de ellos. Por ´ultimo, este tesauro se puede usar libremente, en el marco de un convenio con la Oficina de Publicaciones, en el cual se aceptan las normas que subrayan el debido reconocimiento al origen del tesauro, as´ı como las instrucciones que se deben seguir en el caso de que se proponga la extensi´on del tesauro con nuevos t´erminos (la eliminaci´on de t´erminos est´a en principio restringida, de tal modo que s´olo se decide eliminar t´erminos cuando se publica una nueva versi´on). Eurovoc es un tesauro multiling¨ue cuyo origen se remota a finales de los a˜nos setenta, momento en el que el Parlamento Europeo y la Oficina de Publicaciones Oficiales de las Comunidades Europeas deciden trabajar en la creaci´on de un lenguaje documental com´un. Eurovoc est´a estructurado en 21 campos tem´aticos (dominios) y 127 microtesauros (subdominios). Contiene 6045 descriptores, 7756 no descriptores, 6669 relaciones jer´arquicas rec´ıprocas y 891 notas, datos cuantitativos que muestran el volumen y valor conceptual de esta herramien- 3En adelante Oficina de Publicaciones Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 58 ta terminol´ogica. Eurovoc respeta las normas ISO 2788-1986 e ISO 5564-1985. Desde enero de 2009 est´a disponible la versi´on 4.3. Tras firmar el correspondiente convenio entre la Universidad de Valladolid y la Oficina de Publicaciones, recibimos una copia del tesauro en un CD-ROM. El tesauro se distribuye en un conjunto de ficheros XML, con sus correspondientes DTD, sencillos en su estructura interna, aunque complejos en el n´umero y organizaci´on de los ficheros. No se utiliza SKOS ni ning´un otro est´andar de representaci´on de los vistos en la secci´on 1, raz´on por la cual nos vamos a referir en adelante a este formato como el ’formato propietario XML-Eurovoc de la Oficina de Publicaciones’. Una vez dispon´ıamos de una copia del tesauro, los pasos siguientes son buscar una API para tesauros que nos facilite el desarrollo de aplicaciones, y decidir si vamos a utilizar Eurovoc en el formato en que lo hemos recibido o preferimos una adaptaci´on a SKOS, que parece especialmente indicado para representar tesauros en el marco de la Web Sem´antica [16]. 3. Manipulaci´on y representaci´on del tesauro Eurovoc Existen varias herramientas que permiten manipular tesauros [7,8]. No obstante, hay varios inconvenientes para el uso que pretendemos. Buscamos una herramienta que nos permita abstraernos de las particularidades del almacenamiento del tesauro y c´omo est´a representado. Sin embargo, las herramientas encontradas son aplicaciones de usuario, que permiten crear o manipular tesauros, pero no aportan una API que se pueda utilizar desde otras aplicaciones, que es lo que buscamos. Por otro lado, no es posible importar directamente el tesauro Eurovoc tal cual lo hemos recibido. Esto nos sit´ua ante la necesidad de ocuparnos del almacenamiento del tesauro y su gesti´on desde nuestras aplicaciones. La soluci´on por la que optamos es desarrollar una API gen´erica y utilizarla desde nuestras aplicaciones. Almacenar el tesauro supone escoger un formato de representaci´on, para lo cual consideramos varias alternativas. La primera es almacenar el tesauro en el formato XML en que lo hemos recibido. Esta opci´on se descart´o, ya que al ser un formato propietario, su utilizaci´on cierra la posibilidad de importar directamente cualquier otro tesauro que no est´e representado con este mismo formato, lo cual incluye tesauros representados con est´andares como SKOS. As´ı pues, para facilitar la interoperabilidad, optamos por utilizar una representaci´on est´andar para los tesauros, conforme con la propuesta SKOS. La representaci´on de Eurovoc con SKOS ha sido abordada en varias ocasiones, desde distintos puntos de vista, representando los dominios y microtesauros como esquemas conceptuales (concept scheme) y enlaz´andolos mediante propiedades OWL creadas ad-hoc [11] o representando los dominios como colecciones de esquemas conceptuales, que ser´ıan los microtesauros [6]. De ambas propuestas, que se ajustan a los working draft anteriores al a˜no 2009 [14], hemos estudiado su posible reutilizaci´on. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 59 A pesar de que todas ellas se ajustan a SKOS, son diferentes. Una de las razones de esta diversidad en las soluciones es el hecho de que SKOS no es a´un una Recomendaci´on estable. De hecho, existen varias diferencias entre la versi´on de SKOS de 2008 y la ´ultima Recomendaci´on propuesta, de junio de 2009 [17]. Una de ellas est´a relacionada precisamente con la utilizaci´on de los conceptos Collection yConceptScheme de SKOS, que son utilizados para representar los microtesauros de Eurovoc. La Proposed Recommendation de junio de 2009 introduce una variaci´on respecto a los working draft previos, de modo que ya no se permite que una colecci´on tenga como elementos a esquemas conceptuales. Esto implica que algunas de las propuestas analizadas quedar´an obsoletas una vez se consolide la nueva versi´on como Recomendaci´on estable. Por otro lado, el an´alisis de estas propuestas tambi´en nos lleva a plantearnos las siguientes cuestiones: ¿Son compatibles entre ellas estas propuestas? ¿Ser´an no obstante compatibles entre ellas las nuevas propuestas que se ajusten a la nueva recomendaci´on? Este es un aspecto importante si tenemos en cuenta que los tesauros pueden evolucionar con el tiempo, o si extendemos la experiencia a otros tesauros que no est´en tan f´erreamente controlados en su evoluci´on por alg´un organismo como es el caso de Eurovoc, en cuyo caso pueden sufrir modificaciones a´un con m´as facilidad. La incompatibilidad entre la representaci´on de una versi´on y la posterior nos situar´ıa una vez m´as ante un problema de interoperabilidad. Finalmente, si pensamos en una API gen´erica para tesauros, la cuesti´on que surge es si la elecci´on de una u otra representaci´on condiciona la generalidad de una API y sus implementaciones. La heterogeneidad sint´actica puede solventarse con los lenguajes de consulta apropiados, como SPARQL. Pero la elecci´on entre Collection yConceptScheme, dos estructuras diferentes que SKOS ofrece para representar dominios y subdominios de los tesauros, introduce heterogeneidad en un nivel superior, que no pueden resolver los lenguajes de consulta. 4. Conclusiones La integraci´on de las herramientas de representaci´on de conocimiento utilizadas en distintos sistemas de informaci´on es un reto directamente relacionado con la Web Sem´antica. En este trabajo se ha presentado un caso de aplicaci´on, en el que se pretende utilizar un tesauro ’est´andar’, y se han analizado los posibles problemas de integraci´on que pueden surgir, tanto en el nivel conceptual como en el de representaci´on de los tesauros. En nuestra opini´on una API p´ublica de uso general para tesauros que utilice los est´andares de representaci´on del W3C simplificar´ıa el desarrollo de sistemas que utilizan estas herramientas conceptuales. No obstante, la variedad de propuestas de representaci´on encontradas para el tesauro Eurovoc, y los problemas comentados en las secciones anteriores, demuestra que la integraci´on de conocimiento, tanto a nivel conceptual como formal, encuentra m´as obst´aculos de lo que en principio podr´ıa parecer, incluso cuando se utilizan est´andares para la representaci´on de sem´antica. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 60 Referencias 1. Alvite D´ ıez, M. L. Las bases de datos jur´ıdicas y el uso del lenguaje XML en Espa˜na. SCIRE. Representaci´on y Organizaci´on del Conocimiento 15, 1 (Enero- Junio 2009), 33–57. ISSN 1135-3716. 2. Berners-Lee, T., Hendler, J., and Lassila, O. The Semantic Web. Scientific American (May 2001). 3. Biagioli, C., Francesconi, E., and Sartor, G., Eds. Proceedings of the V Legislative XML Workshop, Florencia, Italia, 14-16 June 2006 (2007), European Press Academic Publishing. 4. Boag, S., Chamberlin, D., Fern´ andez, M. F., Florescu, D., Robie, J., and Sim´ eon, J. XQuery 1.0: An XML Query Language. W3C Recommendation 23 January 2007, W3C, the World Wide Web Consortium, http://www.w3.org/TR/2007/REC-xquery-20070123/, Jan. 2007. 5. Cueto Aparicio, M. Eurovoc thesaurus use at the Senate of Spain. In Information in Africa project workshop (27-30 June 2006). 6. Faro, S., Francesconi, E., Marinai, E., and Sandrucci, V. EUROVOC Studies LOT2 D2.3 -Report on execution and results of the interoperability tests. Tech. Rep. 10118, Publications Office of the EC, Institute of Legal Information Theory and Techniques ITTIG, Jan. 2008. 7. Ferreyra, D. TemaTres: software libre para gesti´on de tesauros. URI: http://www.r020.com.ar/tematres/index.html. 8. Lacasta, J., Nogueras, J., L´ opez-Pellicer, F. J., Muro-Medrano, P., and Zarazaga-Soria, F. ThManager: An Open Source Tool for creating and visualizing SKOS. Information Technology and Libraries (ITAL) 26, 3 (2007), 39–51. 9. Mart´ ınez Gonz´ alez, M. M., Vicente Blanco, D.-J., de la Fuente Redondo, P., Adiego Rodr´ ıguez, J., Pisabarro Marr´ on, A. M., and S´ anchez Felipe, J. M. Estructura, sem´antica, extracci´on de informaci´on y XML legislativo: experiencias en la Universidad de Valladolid. SCIRE. Representaci´on y Organizaci´on del Conocimiento 15, 1 (Enero-Junio 2009), 173–186. ISSN 1135- 3716. 10. Mart´ ınez, M. M., de la Fuente, P., and Derniame, J.-C. XML as a means to support information extraction from legal documents. International Journal of Computer Systems Science and Engineering 18, 5 (Sept. 2003), 263–277. 11. Paredes, L. P., Maria, J., Rodriguez, A., and Azcona, E. R. Promoting Government Controlled Vocabularios for the Semantic Web: the EUROVOC Thesaurus and the CPV Product Classification System. In The Fifth European Semantic Web Conference, 1-5 june 2008, Tenerife, Spain (2008), vol. 50212 of Lecture Notes in Computer Science, Springer, pp. 111–122. 12. Publications Office.Eurovoc thesaurus. Accesible en http://europa.eu/eurovoc (´ultima consulta: 10/07/2009). 13. Vicente, D.-J., Mart´ ınez, M., S´ anchez, J. M., and Adiego, J. Experiences on teaching international private law with the support of an elearning tool. In The LEFIS virtual campus design (Albarrac´ın (Espa˜na), May 2007). Avaible online at http://www.lefis.org/meetings/workshops/2007/albarra cin 2007/contenido/albarracin2007 damaso.ppt. 14. W3C, the World Wide Web Consortium.SKOS Simple Knowledge Organization System Reference. W3C Working Draft 29 August 2008, Aug. 2008. http://www.w3.org/TR/2008/WD-skos-reference-20080829/. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 61 15. W3C, the World Wide Web Consortium.SPARQL Query Language for RDF. W3C Recommendation 15 January 2008, Jan. 2008. http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. 16. W3C, the World Wide Web Consortium.SKOS Simple Knowledge Organization System Primer, June 2009. W3C Working Draft. http://www.w3.org/TR/2009/WD-skos-primer-20090615/. 17. W3C, the World Wide Web Consortium.SKOS Simple Knowledge Organization System Reference. W3C Proposed Recommendation 15 June 2009, June 2009. http://www.w3.org/TR/2009/PR-skos-reference-20090615/. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 62 Generaci´on de Tesauros basado en Media Wiki Ana Flores Cuadrado1, Eduardo Villoslada de la Torre13, y Alberto Pel´aez Guti´errez2 1Telef´onica Investigaci´on y Desarrollo Parque Tecnol´ogico de Boecillo, Parcela 120, 47151. Boecillo. Valladolid, Espa˜na {anafc,evdlt}@tid.es 2Telef´onica Soluciones Parque Tecnol´ogico de Boecillo, Parcela 120, 47151. Boecillo. Valladolid, Espa˜na {albertojavier.pelaezgutierrez}@telefonica.es 3Universidad de Valladolid, Edificio TIT. Campus “Miguel Delibes” s/n, 47011. Valladolid, Espa˜na Resumen. La Wikipedia alberga a trav´es de su estructura, de forma impl´ıcita, un conjunto de relaciones conceptuales muy detalladas y evoluci´on din´amica. Con el objetivo de aprovechar esa informaci´on para mejorar los procesos de b´usqueda en los sistemas de gesti´on del conocimiento, se ha definido un algoritmo que permita materializar la estructura conceptual de la Wikipedia y sus relaciones para construir un tesauro. Palabras clave: Tesauros, SKOS, MediaWiki, Wikipedia, screen scrapper 1. Introducci´on Los sistemas de gesti´on del conocimiento de una empresa tienen como objetivo compartir y difundir el conocimiento sobre tecnolog´ıas y procedimientos entre sus trabajadores. Sin embargo, el rendimiento que se obtienen de estos sistemas es m´ınimo. A menudo, estos sistemas son utilizados como simples repositorios de documentos, donde los usuarios dif´ıcilmente localizan la informaci´on usando buscadores basados en el uso palabras claves [23] o b´usquedas por metadatos. Aunque el uso las tecnolog´ıas sem´anticas y en especial el uso de tesauros [27], puede mejorar la precisi´on de las consultas (recall), existen dificultades para su aplicaci´on en el ´ambito de las tecnolog´ıas de la informaci´on, debido a que no existe ning´un vocabulario espec´ıfico para este ´ambito y que aunque los vocabularios m´as generales como Wordnet [21] incluyen t´erminos de este dominio, su actualizaci´on no es lo suficiente din´amica para soportar la r´apida aparici´on de nuevos conceptos. Con la aparici´on del concepto de Web 2.0 [22], Internet se ha constituido como un veh´ıculo de participaci´on ciudadana que permite la creaci´on y difusi´on del conocimiento de forma din´amica. Una de las herramientas Web 2.0 m´as populares es la Wikipedia [30], donde los usuarios de forma voluntaria se encargan de introducir informaci´on sobre los temas m´as novedosos, en distintos idiomas. En la Wikipedia, cada p´agina o art´ıculo representa un concepto, y la tecnolog´ıa que soporta la Wikipedia permite relacionar de forma impl´ıcita los distintos conceptos, a trav´es de la estructura de sus p´aginas. El objetivo de nuestro trabajo es materializar la estructura conceptual de la Wikipedia, y de sus relaciones y construir con ´el un tesauro que pueda utilizarse en los sistemas de gesti´on del conocimiento para mejorar los procesos de b´usqueda, por una parte, utilizando las relaciones definidas en el tesauro para expandir las consultas [15,14] y as´ı mejorar la precisi´on en las consultas, y por otra utilizar este tesauro como parte de un mapa sem´antico que a modo de asistente vaya guiando a los usuarios en los procesos de b´usqueda, y permiti´endoles navegar a trav´es de los distintas relaciones entre conceptos con el objetivo de refinar las b´usquedas [14]. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 63 En la Secci´on 2 se describen los principales aspectos que son la base tecnol´ogica durante el proceso de construcci´on del tesauro. En la Secci´on 3 se presenta el proceso de mapeo de la estructura de la Wikipedia en base al an´alisis previo de ´esta. En esta secci´on tambi´en se presenta la arquitectura de la aplicaci´on as´ı como el algoritmo utilizado en el proceso de mapeo. La Secci´on 4 presenta los trabajos relacionados y por ´ultimo en la Secci´on 5 se concluye con las ventajas y limitaciones del trabajo presentado y las l´ıneas trabajo futuras. 2. Base Tecnol´ogica El objetivo de esta secci´on es describir los aspectos tecnol´ogicos que son necesarios conocer para comprender el an´alisis realizado de la Wikipedia y la tecnolog´ıa que sustenta la representaci´on de tesauros. 2.1. Tecnolog´ıa Media Wiki Se entiende por Wiki una herramienta web colaborativa, accesible mediante un navegador, cuyo contenido puede ser visualizado y editado directamente por cualquier usuario con permisos sin necesidad de tener unos conocimientos especializados. La primera Wiki fue creada en 1995 por Ward Cunningham [28]. Posteriormente en 2001 se us´o este modelo para crear Wikipedia utilizando un software espec´ıfico para realizar wikis: MediaWiki [18]. Dentro de Wikipedia se distinguen cinco tipos de elementos primarios [11,4]: P´aginas de Art´ıculos: texto que describe un concepto; es la entidad b´asica de Media- Wiki. P´aginas de Re-direcci´on: con el fin de asegurarse de que existe un ´unico art´ıculo por concepto, MediaWiki provee re-direcciones de otros art´ıculos hacia el principal. De esta es la forma se maneja diferentes formas de un mismo t´ermino (por ejemplo: ortograf´ıas m´ultiples, seud´onimos, may´usculas/min´usculas, abreviaturas, sin´onimos) [24]. Enlaces a art´ıculos: dirigen al usuario de un art´ıculo a otro. Las etiquetas de los enlaces no tienen que ser iguales al t´ıtulo del art´ıculo enlazado, pueden usarse sin´onimos, t´erminos relacionados y variaciones ling¨u´ısticas. Categor´ıas: MediaWiki tambi´en ofrece la posibilidad a los autores de incluir categor´ıas a modo de metadatos para la clasificaci´on de art´ıculos. Estas categor´ıas puede ser utilizadas para encontrar art´ıculos relacionados. P´aginas de Desambiguaci´on: P´aginas que contienen un conjunto de enlaces a art´ıculos con los diferentes sentidos que puede tener el t´ermino buscado, es decir, describen m´ultiples conceptos asociados con un mismo t´ermino. 2.2. SKOS Un tesauro es un conjunto de conceptos o t´erminos de un vocabulario controlado organizados en una estructura jer´arquica, d´onde cada t´ermino puede tener una o m´as relaciones padre-hijo con otros t´erminos [27]. En los tesauros es posible representar otro tipo de relaciones como las relaciones de equivalencia o de sinonimia, y las relaciones asociativas o related [12]. Simple Knowledge Organization System (SKOS)[7], es un vocabulario desarrollado por el World Wide Web Consortium (W3C), y que actualmente es el modelo ideal para representar cualquier tipo de vocabulario controlado, y especialmente para representar tesauros en Resource Description Framework (RDF) [16]. A diferencia de Web Ontology Language (OWL) [2,1], que permite expresar estructuras conceptuales complejas donde el tipo de relaciones Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 64 que se establecen entre los elementos depende del dominio, SKOS permite permite la representaci´on de vocabularios m´as complejos, incluyendo ontolog´ıas [5] OWL [25], mediante esquemas sencillos de conceptos. En SKOS, los elementos ´unicamente se pueden relacionar por relaciones jer´arquicas, asociativas o de equivalencia, lo que facilita su tratamiento, cuando se quiere utilizar la navegaci´on entre las relaciones de los elementos como ayuda o asistencia a los usuarios en las b´usquedas. Fig. 1. Representaci´on de un Tesauro usando SKOS En SKOS (figura 1), cada concepto (skos:Concept) se identificada por una Uniform Resource Identifiers (URI) y representa una colecci´on de t´erminos sin´onimos. Uno de los elementos de esta colecci´on es el descriptor del concepto (skos:prefLabel) y se utiliza como identificador ´unico de cada concepto. El resto de los sin´onimos se representan como t´erminos alternativos (skos:altLabel) asociados al descriptor, pudiendo existir un n´umero indefinido de ellos. En el caso de los tesauros multi-idiomas, adem´as se puede establecer relaciones entre un mismo concepto en distintos idiomas, mediante el atributo lang de la etiqueta (skos:prefLabel). Aunque s´olo es posible definir una etiqueta preferida por idioma y tantas etiquetas alternativas como se desee en los diferentes idiomas. An´alogamente a los tesauros, las relaciones sem´anticas que se pueden establecer en SKOS son relaciones jer´arquicas, donde el t´ermino padre (skos:broader) suele representar el t´ermino m´as amplio o gen´erico y el termino hijo representa al m´as concreto o especifico (skos:narrower). Las relaciones de equivalencia o entre sin´onimos se representa con las etiquetas (skos:altLabel)y(skos:prefLabel). Y finalmente se pueden establecer relaciones asociativas orelated entre t´erminos del tesauro que no est´an dentro de la misma jerarqu´ıa, pero que tienen cierta relaci´on entre ellos mediante la etiqueta (skos:related). Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 65 3. Proceso de Construcci´on del Tesauro En esta secci´on se presenta el proceso de mapeo de la estructura de la Wikipedia y de construcci´on del tesauro, as´ı como la arquitectura de la aplicaci´on utilizada para efectuar el proceso de mapeo. 3.1. An´alisis de la informaci´on de la Wikipedia La forma de realizar la extracci´on de la informaci´on de Media Wiki y de realizar la transformaci´on entre sus elementos y los conceptos de SKOS (secci´on 2.2) hay que establecerla bas´andose en los contenidos de la MediaWiki (secci´on 2.1). Esta transformaci´on no es ´unica, sino que pueden darse distintas interpretaciones y pueden generarse distintos algoritmos en funci´on de los objetivos del tesauro a generar. Fig. 2. Esquemas de las p´aginas de categor´ıas ya art´ıculos. El algoritmo aqu´ı propuesto trata de ofrecer una visi´on m´as general e independiente del dominio del tesauro. Para generar este algoritmo se ha analizado la estructura de las p´aginas de MediaWiki para determinar su relaci´on con cada elemento del vocabulario SKOS. Para ello, en la figura 2 se muestran las distintas partes de las p´aginas de categor´ıas y de art´ıculos de donde se extrae la informaci´on que almacenar´a el fichero SKOS. La conclusion obtenida del an´alisis es la siguiente: Identificador del concepto (skos:Concept): Se obtiene de la Uniform Resource Locator (URL) de la p´agina de la wikipedia. El descriptor o elemento identificador del concepto (skos:prefLabel): Se obtiene directamente de la parte final URL de los enlaces. El conjunto de sin´onimos o Alternatives (skos:altLabel): Ser´an las redirecciones a la p´agina actual y se obtiene de los enlaces cuyo id de la p´agina mw-whatlinkshere-list (Lo que enlaza aqu´ı). La relaciones jer´arquicas (padre-hijo) o Broader/Narrower: Cada art´ıculo o categor´ıa pertenece a una o varias categor´ıas, que son asignadas como skos:broader. Se identifican como aquellos enlaces cuyo id es mw-normal-catlinks. La asignaci´on de skos:narrower no se realiza de forma expl´ıcita, sino que se dise˜na el software para que cuando se asigna un t´ermino broader, el tesauro incluya autom´aticamente la relaci´on narrower correspondiente. La relaciones asociativas (skos:related): La estructura de las p´aginas de categor´ıas y de art´ıculos es diferente, por lo hay que diferenciar: Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 66 automáticamente. Un problema de la Web Semántica es el de alcanzar un entendimiento entre usuario, desarrollador y aplicaciones, y para conseguirlo se hace uso de las ontologías. La idea fundamental es que la Web Semántica esté formada por una red de nodos tipificados e interconectados mediante clases y relaciones definidas por una ontología compartida por sus distintos autores. Pero no todo serán redes y compartición de recursos, las aplicaciones Web también proporcionan servicios. Los Servicios Web Semánticos proponen describir no sólo información sino funcionalidades y procedimientos para describir Servicios Web: sus entradas y salidas, las condiciones necesarias para que se puedan ejecutar, los efectos que producen, o los pasos a seguir cuando se trata de un servicio compuesto. Dichas descripciones procesables por máquinas permitirían automatizar el descubrimiento, la composición, y la ejecución de servicios, así como la comunicación entre unos y otros. En este contexto WSMF [2] tiene como objetivo era el de permitir un E-commerce basado en Servicios Web de una manera completa, escalable y flexible. Para ello, WSMF provee el modelo conceptual apropiado para desarrollar y describir Servicios Web y sus composiciones. Se basa en dos principios complementarios: fuerte desacoplamiento de los múltiples componentes que realiza una aplicación de E- commerce y fuerte servicio de mediación, que permite a cualquier aplicación comunicarse con otros servicios y aplicaciones de una manera escalable. Por otro lado, como alternativa más cercana a los estándares del W3C surge OWL- S [3], que define una ontología OWL de servicios producto del esfuerzo colaborativo de investigadores de varias organizaciones. Esta ontología sigue en pleno desarrollo, y conectándose con diversos proyectos, como aquellos consistentes en construir ontologías de tiempo y recursos. A menudo, OWL-S es referido como un lenguaje para describir servicios, reflejando el hecho de que nos proporciona un vocabulario estándar que puede usarse junto con los otros aspectos del lenguaje OWL para crear descripciones de servicios. Pese a estar basado en OWL existen pocas herramientas que den soporte a la anotación de servicios Web mediante OWL-S, y las herramientas existentes resultan muy complejas para esta tarea. Sin embargo WSMF proporciona un entorno integrado de diseño de anotaciones sobre servicios Web de uso más sencillo, WSMO Studio [4]. En este artículo presentamos una extensión de WSMO Studio para el diseño de anotaciones de servicios Web con OWL-S. De esta forma los desarrolladores de servicios Web semánticos pueden hacer uso de un entorno unificado para diseñar anotaciones para estos servicios usando ambas propuestas. En la Sección 2 se describen los trabajos relacionados con la herramienta presentada en este artículo. La Sección 3 presenta dicha herramienta, OWL-S Modeller. Finalmente, la Sección 4 introduce las conclusiones y trabajos futuros. 2 Trabajos relacionados Existen distintas aplicaciones para la generación de descripciones de Servicios Web en OWL-S. A continuación veremos algunas de objetivos similares a la herramienta presentada en este artículo. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 73 University of Malta OWL-S Editor [5] es una aplicación orientada a para ayudar a los usuarios o programadores inexpertos a crear descripciones de Servicios Web en OWL-S. La creación de descripciones se realiza mediante asistentes que van pidiendo los atributos necesarios en cada momento. Una vez terminado el proceso genera el archivo con la descripción OWL-S. La construcción de descripciones no es dinámica, ya que hay que realizar todos los cambios a la vez para la posterior creación del documento. Tiene la opción de editar descripciones existentes, pero con el mismo sistema de asistentes que dan poco dinamismo a la tarea. Por otro lado, se pueden visualizar los grafos de las descripciones, pero no permite realizar cambios gráficamente. CMU’s OWL-S Development Environment (CODE) [6] es un ambicioso proyectoque pretende aprovechar todos las herramientas para la Web Semántica desarrolladas por CMU, desde el parser, pasando por el generador de WSDL desde código Java, el conversor de WSDL a OWL-S, y terminando por OWL-S Editor. De entre las herramientas integradas en CODE, la más relevante para los propósitos del trabajo presentado en este artículo es CMU OWL-S IDE [7], un entorno de desarrollo de OWL-S en el cual se incluye el plug-in CMU OWL-S Editor. Se trata de un plugin de eclipse que pretende realizar todas las funciones de tratamiento de documentos OWL-S: creación, edición, composición, etc. También cuenta con un Process Editor, que permite crear descripciones de procesos. Protègè [8] es actualmente la plataforma más usada y conocida para la construcción de ontologías para la Web Semántica, particularmente ontologías OWL. Se trata de una plataforma libre, cuyo propósito es poder modelar bases de conocimiento. Este entorno de desarrollo permite crear dominios de conocimiento mediante una interfaz gráfica y de fácil uso, aunque de un uso más técnico y complejo que la aplicación OWL-S Editor vista anteriormente. Protègè puede ser extendido gracias a la arquitectura de plug-ins que posee y a la API basada en Java para la creación de herramientas y aplicaciones de bases de conocimiento. Esto ha hecho que se genere en torno una comunidad que contribuye activamente ampliándolo mediante la creación de plug-ins, lo que lo convierte en una herramienta bastante potente. Existe un plug-in para Protègè pensado en OWL-S, llamado también OWL-S Editor [9]. Dicho editor es un entorno gráfico para creación y edición de descripciones OWL-S. El plug-in OWL-S Editor es excesivamente técnico y poco intuitivo como para la utilización por parte de usuarios poco experimentados, siendo las generaciones de descripciones más textuales que gráficas y mostrando los árboles de procesos mediante estructuras tipo browser como JTree1. OWL-S Matcher (OWLSM) [10] nace de una herramienta similar para descripciones DAML-S, es una implementación Java de un algoritmo matchmaking para emparejar descripciones OWL-S. La aplicación compara dos descripciones (una del que realiza la petición del servicio y otra del que lo proporciona) e identifica las diferentes relaciones entre ambas descripciones. Esta comparación se realiza mediante la evaluación de las entradas y salidas de cada proceso, además de las categorías del servicio. WSMO Studio [4] es el sucesor de SWWS Studio, y como tal, se trata de un entorno de desarrollo código abierto para el modelado de Servicios Web Semánticos y 1 http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JTree.html Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 74 procesos de negocios semánticos. Este entorno es un conjunto de plug-ins de Eclipse, lo que le proporciona una gran extensibilidad, permitiendo a las comunidades de usuarios poder desarrollar herramientas para esta aplicación del mismo modo que se realizan para Eclipse. WSMO Studio está desarrollado por el grupo Ontotex Lab. Se trata de un “entorno de servicios integrado” (Integrated Service Environment). Dicho entorno pretende dar soporte y elaborar la perspectiva abierta por WSMF y WSMO [11], haciendo estas tecnologías transparentes y de fácil uso para el usuario. Esto último se consigue gracias a la interfaz gráfica proporcionada por Eclipse. La filosofía de WSMO Studio es la de considerar que es importante que la funcionalidad relevante a los dominios de los Servicios Web Semánticos esté presente de una forma que maximice el valor que proporciona. De entre todas las funcionalidades de WSMO Studio, la que más nos interesa es la de poder manejar documentos BPMO. Esto se consigue gracias al plug-in BPMO Modeller, que se incluye en WSMO Studio. Este plug-in permite la creación y edición de procesos de negocios usando todos los conceptos disponibles de una manera totalmente gráfica y sin necesidad de tener amplios conocimientos acerca de WSMO, WSDL o WSML. BPMO Editor consigue ahorrar de este modo la compleja tarea, propensa a errores, de tener que escribir directamente las descripciones de los procesos de negocio. 3 OWL-S Modeller OWL-S Modeller es el nombre que se le ha dado a la herramienta objeto de este artículo. Este nombre proviene de la aplicación análoga de WSMO Studio, BPMO Modeller, cuyo objetivo es similar al de este estudio, pero empleando la ontología BPMO en lugar de OWL-S. El objetivo principal de OWL-S Modeller es el de realizar una herramienta gráfica que permita generar descripciones de Servicios Web Semánticos en OWL-S a partir de un grafo de procesos. Dicha herramienta toma una ontología y permite al usuario poder generar una descripción de un Servicio Web mediante la composición de procesos que usan conceptos de dicha ontología. Una vez se diseña el grafo con forma de árbol, se crea de forma totalmente automática una descripción de un Servicio Web basada en los conceptos obtenidos de la ontología proporcionada y tomando como modelo de procesos el grafo diseñado. Esta forma de generar descripciones proporciona al usuario una visión general que difícilmente se conseguiría con un interfaz textual, lo que permite que personas sin conocimientos acerca de los lenguajes en los que se describen los Servicios Web Semánticos puedan crear descripciones para compartir sus recursos o aplicaciones. De este modo se consigue acercar OWL-S y la Web Semántica a los usuarios con conocimientos más básicos. Con OWL-S Modeller se pretende acercar el uso de las tecnologías de la Web Semántica a todos los usuarios, de modo que sea posible la generación de descripciones de Servicios Web Semánticos sin los conocimientos sobre los lenguajes para su implementación. De esta forma el usuario sólo tiene que preocuparse de la semántica de los servicios, sin necesidad de dedicar esfuerzos a la sintaxis o Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 75 estructuración del código. Esto se consigue gracias al modelado de descripciones usando árboles de procesos en los que hay que identificar las entradas y las salidas de dichos procesos con conceptos de la ontología deseada. La aplicación está compuesta por varias vistas, tal y como se puede observar en la Figura 1. 3.1 Navegador del Proyecto El área del navegador del proyecto funciona exactamente igual que como lo hace en Eclipse y WSMO Studio. Es decir, se muestran los proyectos existentes en el espacio de trabajo clasificados en forma de árbol de carpetas. Dentro de cada proyecto se anidan los documentos pertenecientes a dicho proyecto, tanto los trabajados como los auxiliares (documento layout, por ejemplo). Estos proyectos y documentos pueden ser manipulados del mismo modo que se pueden manipular en el explorador de Windows, permitiendo copiarlos, renombrarlos, moverlos, etc. Desde éste área pulsando el botón derecho aparecerá un menú contextual que ofrecerá múltiples posibilidades, entre ellas las de crear un proyecto o documento OWL-S nuevo. 3.2 Paleta de Procesos La paleta es un elemento esencial de la creación de diagramas, en ella se encuentran contenidos todos los gráficos dibujables (nodos y conectores). En la Figura 1 se muestra la paleta, de donde se distinguen cuatro tipos de componentes:  Palette. En este grupo se encuentran las acciones de la paleta incluidas por defecto. Es decir, la de seleccionar objetos (select) y la de seleccionar objetos en grupo (marquee).  General. En este grupo se ha incluido sólo el proceso atómico, que sería posteriormente el elemento que formará los nodos hoja del árbol de procesos. Para hacer uso de los procesos atómicos sería necesario seleccionarlos en la paleta y luego seleccionar el lugar en el diagrama donde se quieran ubicar.  Connections. Se encuentra una única conexión dirigida que irá de padre a hijo. Para usarla se selecciona en la paleta, luego se selecciona el padre para finalmente seleccionar al hijo, lo que automáticamente creará la conexión. El posicionamiento de la conexión se realiza automáticamente y se actualiza cada vez que se decida mover alguno de los nodos que conecta.  Control Constructs. En este grupo se incluyen todas las estructuras de control proporcionadas por OWL-S. Los nodos de este tipo que contengan estructuras condicionales vendrán con una condición seleccionada por defecto, pero resulta recomendable verificar que sea la deseada. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 76 Figura 1. Interfaz de usuario 3.3 Área de Modelado En el área de modelado (Figura 1) será donde se dibujen todos los modelos de árboles de procesos. Inicialmente será una pantalla en blanco (que será considerada el fondo del diagrama), que posteriormente se irá conteniendo nodos y conexiones procedentes de la paleta. Los objetos que se dibujen tendrán toda libertad de “movimiento" y de “tamaño" en el sentido de que el usuario puede ubicarlos y reubicarlos constantemente a la vez que variar los tamaños de los mismos siempre y cuando no se sobrepongan. El área de modelado cuenta con menús contextuales que dependen del objeto sobre el que se ejecute la pulsación del botón derecho del ratón. Por ejemplo, el menú contextual del fondo del diagrama ofrece la posibilidad de exportar la imagen actual, actualizar el navegador OWL y reubicar todos los elementos. Como hemos indicado, los nodos se añaden al diagrama haciendo uso de la paleta (seleccionando un objeto y luego haciendo click en el fondo del diagrama donde queramos que se sitúe). Una vez un nodo haya sido dibujado, se pueden realizar distintas operaciones sobre él (algunas dependen del tipo de nodo). Todos los nodos dibujados pueden moverse libremente arrastrándolos y permiten cambiar de tamaño arrastrando sus bordes. Cada nodo posee un nombre situado en la parte superior (en el nodo de ejemplo corresponde a “New Control Construct"). Dicho nombre se puede cambiar bien haciendo doble click sobre el nodo o abriendo el menú contextual del nodo y pulsando “rename". Además del nombre, cada nodo dispone de un tipo de nodo y un icono correspondiente que se encuentran en la parte inferior del nodo (en el nodo de ejemplo este tipo corresponde a “Sequence"). Por otro lado, los nodos contienen nodos de eventos internos que permiten arcos de entrada y de salida. Se diferencian dos tipos de nodos de evento: nodo final y nodo inicial. El nodo final es el nodo que recibe los arcos procedentes de otros nodos mientras que el nodo inicial es de donde Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 77 parten dichos arcos. Los procesos atómicos sólo tienen nodo final, dado que de ellos no saldrá ningún arco. A la hora de realizar las conexiones, concretamente al seleccionar un nodo, el arco apuntará automáticamente al nodo evento que debe apuntar, por lo que no hay que seleccionar el nodo evento. . Figura 2. (Izquierda) Menú contextual de un nodo (proceso) atómico. (Derecha) Creación de una entrada a un proceso atómico usando conceptos de la ontología usada para la anotación del servicio Web. Los procesos atómicos son un tipo especial de nodo, dado que son los que componen el árbol de procesos que finalmente generará la descripción del Servicio Web. Para que esta acción pueda llevarse a cabo se tienen que definir una serie de entradas y salidas de los procesos que serán conceptos de la ontología. En la Figura 2 (Izquierda) se muestra el menú contextual para un proceso atómico con una salida. En dicho menú se ven dos opciones comunes para todos los procesos atómicos: “Add input" y “Add output". Estas acciones permiten añadir las entradas y las salidas necesarias para poder generar la descripción deseada. La Figura 2 (Derecha) muestra el caso específico de la adición de una entrada. Se observa el diálogo que aparece donde se puede introducir el nombre de dicha entrada y su tipo. El tipo de la entrada viene dado por una lista desplegable que contiene todos los conceptos y propiedades incluidos en la ontología base de forma que el usuario no debe copiar la URL de los conceptos de otro sitio, aportando comodidad a la utilidad. En el ejemplo se ha decidido nombrar la entrada como “nueva entrada" y seleccionar el tipo “Platoon". El caso para las salidas es totalmente análogo al de las entradas, por lo que queda explicado. 3.4 OWL Navigator La vista del navegador se muestra por defecto en la parte inferior izquierda del interfaz de la aplicación. El objetivo de esta parte de la vista de la aplicación es el de permitir desglosar las ontologías base de las descripciones para poder observar jerárquicamente los contenidos de dichas ontologías OWL. Por lo tanto, el contenido Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 78 del diagrama dependerá directamente de la ontología base del editor actual. Sin embargo, cuando se cambia de un editor asociado a un documento a otro, no se actualiza automáticamente el contenido del navegador. Para ello se ha aportado la funcionalidad de actualizar el navegador en base al editor activo actual mediante el menú contextual del diagrama (Figura 3), que actualizará inmediatamente el contenido del navegador para mostrar la ontología OWL atribuida al editor activo. El navegador es un explorador de los elementos de la ontología OWL empleada. Estos elementos se clasifican en clases y propiedades. Dentro de cada clase se muestran las propiedades en las que intervienen y las instancias existentes. Por ejemplo, en la Figura 3 se muestra la clase Platoon que participa en la propiedad contains que tiene como dominio la clase Unit y como rango la clase Thing. Además se observa en la Figura 3 la clase Company, que tiene la instancia Easy. Las propiedades existentes se clasifican a su vez en tipos: propiedades funcionales, propiedades de ontología y propiedades de tipos de datos. Figura 3. Navegación por la ontología seleccionada 3.5 Opciones del Menú El proceso de exportación de un diagrama gráfico al modelo de procesos en un archivo OWL-S se lleva a cabo en el momento en el que se desea guardar dicho diagrama. Por lo tanto, para exportar el diagrama actual tan sólo se debe ir a "File", “Save" o bien pulsar “CTRL+S". En este momento se iniciará la validación de modelo y, en caso de cumplir con todas las restricciones, se procederá a la conversión. En caso contrario aparecerá un mensaje indicando los errores encontrados. Si no se cumplen los requisitos, dicho diagrama no se podrá guardar y por tanto no se podrá cargar en un futuro para continuar diseñándolo. En caso de decidir guardarlo aún Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 79 existiendo errores, con bastante probabilidad dicho diagrama no se guardará correctamente y no sea posible volver a cargarlo. Por este motivo, se recomienda guardar sólo cuando el modelo esté correctamente construido y validado. 4 Conclusiones La propuesta principal de integración de aplicaciones es reemplazar la diversidad de interfaces independientes por una aproximación ordenada utilizando un núcleo central, reduciendo costos de mantenimiento. Los diferentes modelos de integración de aplicaciones permiten compartir datos y procesos de negocios a través de diferentes sistemas, en forma independiente del sistema operativo, el lenguaje de programación o el soporte de datos. Las tecnologías para la Web están avanzando constantemente con nuevas iniciativas. De entre estas iniciativas, la Web Semántica pretende dotar de semántica a todos los datos contenidos en la Web, permitiendo de este modo proporcionar los mecanismos necesarios a las máquinas para que comprendan la información. Además, se pretende convertir la Web en una red de datos en lugar de la red de aplicaciones que controlan los datos que es actualmente. Con ello se conseguiría que existiese una interoperabilidad estandarizada entre aplicaciones Web. La Web Semántica va poco a poco convirtiéndose en una realidad, prueba de ello son aplicaciones ya implantadas como RSS y FOAF. Pronto será posible acceder a los recursos de la Web a través de sus contenidos en lugar de hacerlo mediante palabras claves, tal y como se realiza actualmente. Para que esta situación sea posible, es necesario el desarrollo de lenguajes de ontologías que permitan modelar todos los conceptos necesarios para la Web Semántica. Este trabajo se ha centrado en OWL y WSMO, que aportan niveles de expresividad diferentes pero, manteniendo el objetivo común de hacer posible la Web Semántica. La integración es una tarea cada vez mas frecuente en las empresas, y que además de tener un alto coste suele consumir muchos recursos. Para tales empresas la necesidad de integración es, en gran parte, consecuencia de la evolución natural de su negocio. OWL-S Modeller se presenta como una herramienta diseñada precisamente para realizar esta tarea. A pesar de la existencia de múltiples proyectos relacionados, las principales ventajas de esta herramienta es que aúna de forma integrada tanto el diseño de anotaciones de servicios Web usando WSMO y OWL-S. Esta extensión de WSMO Studio permite por tanto que desarrolladores acostumbrados al mismo puedan realizar anotaciones mediante OWL-S, y para aquellos desarrolladores no acostumbrados a WSMO Studio se ofrece una herramienta basada en Eclipse, facilitando su aprendizaje. Agradecimientos. Trabajo financiado por el proyecto ICARIA TIN2008-04844 (Ministerio de Ciencia e Innovación). Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 80 Referencias 1. Berners-Lee, Tim: A roadmap to the Semantic Web. Informe técnico, septiembre 1998. http://www.w3.org/DesignIssues/Semantic.html. 2. Jos de Bruijn, Rubén Lara, Sinuhé Arroyo, Juan Miguel Gomez, Sung-Kook Han and Dieter Fensel: A Unified Semantic Web Services Architecture based on WSMF and UPML, In International Journal on Web Engineering Technology, special issue on Semantic Web, 2005. 3. David Martin, Massimo Paolucci, Sheila McIlraith, Mark Burstein, Drew McDermott, Deborah McGuinness, Bijan Parsia, Terry Payne, Marta Sabou, Monika Solanki, Naveen Srinivasan, Katia Sycara, "Bringing Semantics to Web Services: The OWL-S Approach", Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition (SWSWPC 2004), July 6-9, 2004, San Diego, California, USA. 4. Dimitrov, M., Simov, A., Momtchev, V., and Konstantinov, M. 2007. WSMO Studio --- A Semantic Web Services Modelling Environment for WSMO. In Proceedings of the 4th European Conference on the Semantic Web: Research and Applications (Innsbruck, Austria, June 03 - 07, 2007). E. Franconi, M. Kifer, and W. May, Eds. Lecture Notes In Computer Science, vol. 4519. Springer-Verlag, Berlin, Heidelberg, 749-758. 5. Scicluna, J., C.Abela y M. Montebello: Visual Modelling of OWL-S Services. En IADIS International Conference WWW/Internet, octubre 2004. Madrid Spain. 6. Srinivasan, Naveen, Massimo Paolucci y Katia Sycara: CODE: A Development Environment for OWL-S Web Services. Informe técnico, 2004. http://iswc2004. semanticweb.org/demos/10/paper.pdf. 7. Srinivasan, N., Paolucci, M., and Sycara, K. 2006. Semantic Web Service Discovery in the OWL-S IDE. In Proceedings of the 39th Annual Hawaii international Conference on System Sciences - Volume 06 (January 04 - 07, 2006). HICSS. IEEE Computer Society, Washington, DC, 109.2. 8. T. Tudorache, N. F. Noy, S. W. Tu, M. A. Musen. Supporting collaborative ontology development in Protégé. Seventh International Semantic Web Conference, Karlsruhe, Germany, Springer. Published in 2008 9. D. Elenius. The OWL-S Editor – A Domain-Specific Extension to Protégé. 8th International Protégé Conference, July, 2005. 10. Jaeger, Michael C., Gregor Rojec-Goldmann, Christoph Liebetruth, Gero M uhl y Kurt Geihs: Ranked Matching for Service Descriptions Using OWL-S. KiVS, páginas 91-102, 2005. 11. Dumitru Roman, Uwe Keller, Holger Lausen, Jos de Bruijn, Rubén Lara, Michael Stollberg, Axel Polleres, Cristina Feier, Christoph Bussler, and Dieter Fensel: Web Service Modeling Ontology, Applied Ontology, 1(1): 77 - 106, 2005. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 81 A Model Transformation-based Technique for Flexible XML Data Source Integration Mar´ıa P´erez, Ismael Sanz, Mar´ıa Jos´e Aramburu, and Rafael Berlanga? Universitat Jaume I de Castell´o, Spain {mcatalan,isanz,aramburu,berlanga}@uji.es Abstract. Current research in domains such as Bioinformatics depends heavily on the integration and processing of information coming from diverse sources, which are typically highly complex and heterogeneous, and require approximate queries based on a ranking method. Processing these sources requires sophisticated query processing techniques, which are based on indexing and optimization techniques which are highly specific to the chosen ranking method. In this work we present a technique for the selecting appropriate ranking methods for complex sources, which is useful to drive the development of targeted information systems, using model transformations. We describe the general approach, its application context, and showcase it using examples of an i∗profile and ATL transformations. 1 Introduction A number of important applications are based around approximate queries that return ranked results. The classical examples arise in textual Information Retrieval and multimedia databases. Many different approaches have been proposed in both fields, usually build around a given notion of “similarity” which is used for ranking results. Traditionally, systems in these fields have been build and optimized around the chosen notion of similarity, developing adhoc query processing techniques and indexing structures; the selection of a different ranking method requires building and testing a new system. The emergence of new applications fields which also require the use of approximate queries, and the fact that many of these systems require integrating heterogeneous data sources, has caused serious problems in system development. As a case study, we fill focus on the bioinformatics research community, which produces a vast amount of information in the form of large databases of complex data [4], typically available in XML. These databases are highly heterogeneous, contain complex domain-specific data (such as protein sequences or metabolic networks), and are usually very specific to a particular subfield. Typical workflow in the field require approximate queries, and are built in the context of information systems that must store, integrate and process these databases [5]. As a consequence, several techniques and standards developed in the context of Enterprise Information Integration systems have been used to build research-oriented applications, including Data Warehouses, mediator-oriented architectures and peer data management systems [9]. Nevertheless, the development of such systems is mostly performed in an adhoc way, with reusable frameworks providing only minimal scaffolding [8]. This makes it very costly to create even relatively simple, small-scale integrated systems. A major reason for this state of affairs are the distinct requirements of Bioinformaticsoriented systems, when compared with standard enterprise applications. These are caused by the qualitatively different nature of the underlying data that must be processed in the Bioinformatics case: the high complexity of the data and the need to deal with very large ?Supported by grant TIN2008-01825 of the Spanish Ministry of Science and Innovation. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 82 of a similarity function at a given granularity level, or as a composition of other measure components. These components are combined in the Measures model by using basic combinators such as a weighted sum. In addition, every component can be parametrized; for instance, a component that computes similarity at the textual level may allow the user to choose whether common words (“stop words”) must be considered. Using this framework, a large number of functions with different requirements can be defined. 2. User model. It contains information about the last queries executed by the user. This information may help in the selection or parameterization of the measures. 3. Collection model. It contains a summary of the characteristics of the targeted collections. This summary characterized the level and the type of heterogeneity that each collection has. It is used to select and describe the specific tasks in the Specific Task model and to design the similarity measures. These models make possible the integration of heterogeneous collections, allowing the users to describe their requirements without determining where and how the data is located. As an example, we show one of the rules that form the ATL transformation defined between the Requirements profile and the Specific Task profile. This rule matches any type of Content and Structure (CAS) requirement into two specific tasks: (i) a Structural search task and (ii) a Text search task with their corresponding parameters. rule CAS{ from s:UML2!Class (s.hasDeterminedStereotype(’CAS’)) to t : MMb!Class(name<−s.name), d : MMb!Class(name<−s.name) do { thisModule.Global UmlModel.packagedElement <− thisModule.Global UmlModel.packagedElement −>including(t); t. applyStereotype(UML2!Stereotype.allInstances()−> select (st |st .name = ’Structural search ’ ). first ()); t .setValue(t. getAppliedStereotype(’STM::Structural search ’ ), ’Pattern’ , s.getTagValue(’CAS’,’Pattern’ )); thisModule.Global UmlModel.packagedElement <− thisModule.Global UmlModel.packagedElement −>including(d); d.applyStereotype(UML2!Stereotype.allInstances()−> select (st |st .name = ’Text’). first ()); d.setValue(d.getAppliedStereotype(’STM::Text’), ’Keywords’, s.getTagValue(’CAS’,’Keywords’)); } } where hasDeterminedStereotype(Stereotype) andgetTagValue(Stereotype, Attribute) are helper functions. The former checks if the each element of the input model has a determined stereotype and the latter obtains the value of an attribute specific of its stereotype. A prototype of the tools described in this paper has been implemented in Eclipse. Figure 5 shows a screenshot displaying the structure of some candidate ranking functions obtained, which would go on to be assessed using the techniques outlined in [10] in order to obtain the final functions to be implemented in our example case study. 6 Discussion and Future work We have outlined a method to help development of systems which are strongly driven by the implementation of ranking functions. Mistakes in the specification can be costly, and Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 89 Fig. 5. A screenshot of Eclipse showing the obtained candidate measures after applying the transformations Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 90 our main goal is to ensure that the selected functions are as close as possible to the information requirements of the users, in order to avoid the useless implementation of the wrong processing and indexing components. We consider our initial results encouraging. The models and transformations that we have developed and that we describe in this paper form a good basis for further developments. Our immediate goal is to continue experimenting with realistic examples in order to further refine the models and transformations used in our approach. Eventually, we plan to incorporate the techniques outlined in this work into a more comprehensive methodology which can be used for guiding all aspects of bioinformatics-oriented information systems development, allowing for better maintainability and reusability of such systems and building specific tools to support the developers. References 1. Biopax. http://www.biopax.org/. 2. ATLAS team: ATLAS Transformation Language (ATL) Home page, 2006. 3. S. Adalı, P. Bonatti, M. L. Sapino, and V. S. Subrahmanian. A multi-similarity algebra. In SIGMOD ’98, pages 402–413, New York, NY, USA, 1998. ACM Press. 4. Michael Y. Galperin and Guy R. Cochrane. Nucleic Acids Research annual Database Issue and the NAR online Molecular Biology Database Collection in 2009. Nucleic Acids Res., 37:D1–4, Jan. 2009. 5. Carole Goble and Robert Stevens. State of the nation in data integration for bioinformatics. Journal of Biomedical Informatics, 41(5):687–693, Oct. 2008. 6. G. Grau, C. Cares, X. Franch, and F.J. Navarrete. A comparative analysis of i* agent-oriented modelling techniques. In Proceedings of the 18th International Conference on Software Engineering and Knowledge Engineering (SEKE 2006), pages 657–663, July 2006. 7. Jose-Norberto Maz´on, Jes´us Pardillo, and Juan Trujillo. A Model-Driven Goal-Oriented Requirement Engineering Approach for Data Warehouses. In ER Workshops, pages 255–264, 2007. 8. Marco Mesiti, Ernesto Jim´enez-Ruiz, Ismael Sanz, Rafael Berlanga, Paolo Perlasca, Giorgio Valentini, and David Manset. XML-based approaches for the integration of heterogeneous bio-molecular data. BMC Bioinformatics, in press, 2009. 9. Marco Mesiti, Ernesto Jim´enez-Ruiz, Ismael Sanz, Rafael Berlanga, Giorgio Valentini, Paolo Perlasca, and David Manset. Data integration issues and opportunities in biological XML data management. In Eric Pardede, editor, Open and Novel Issues in XML Database Applications: Future Directions and Advanced Technologies. IGI Global, 2009. 10. Mar´ıa P´erez, Ismael Sanz, and Rafael Berlanga. Measure assessment for heterogeneous XML collections. In JISBD 2008, 2008. 11. S. Raghavan, G. Zelesnik, and G. Ford. Lecture Notes on Requirements Elicitation. Education Materials. CMU/SEI-94-EM-10. Software Engineering Institute. Carnegie Mellon University, Pittsburgh, PA 15213 (USA), 1994. 12. Ismael Sanz, Marco Mesiti, Giovanna Guerrini, and Rafael Berlanga. Fragment-based approximate retrieval in highly heterogeneous XML collections. Data & Knowledge Engineering, 64(1):266–293, January 2008. 13. Robert Stevens, Carole Goble, Patricia Baker, and Andy Brass. A classification of tasks in bioinformatics. BIOINFORMATICS, 17:180–188, 2001. 14. Eric Yu. Modelling Strategic Relationships for Process Reenginering. PhD thesis, University of Toronto, Canada, 1995. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 91 Integración de Aspectos de Calidad de Datos en Sistemas de Información Ismael Caballero, Mª Ángeles Moraga, Coral Calero Universidad de Castilla–La Mancha Grupo Alarcos - Instituto de Tecnologías y Sistemas de la Información Pº de la Universidad 4, 13071 Ciudad Real (Spain) { MariaAngeles.Moraga,Ismael.Caballero, Coral.Calero}@uclm.es Abstract. Para desarrollar con éxito una tarea es imprescindible que los usuarios de información puedan disponer de datos con los niveles adecuados de calidad. Para tomar una decisión sobre si usar o no los documentos, necesitan tener una evaluación de esos niveles. Para evaluarlos, es necesario disponer de un modelo de calidad de datos. Como quiera que la evaluación depende del contexto, y unos mismos datos deben estar disponibles para varios contextos, entonces toda la infraestructura de evaluación debe estar disponible para ser accedida desde distintas aplicaciones. Esto requiere que los datos estén adecuadamente descritos para que puedan ser entendidos. Este artículo plantea algunos de los retos de investigación que estamos afrontando, como por ejemplo la posibilidad de aplicar los principios de LinkedData para anotaciones de calidad de datos, o como aplicar los resultados que vayamos obteniendo a los datos almacenandos en bases de datos heredadas, de modo que puedan ser utilizados en entornos distintos para los que fueron plantearon, de forma que puedan seguir siendo utilizados. Palabras Clave: Calidad de Datos, Dimensiones de Calidad de Datos, Web Semántica, Integración, Evaluación de Calidad de Datos, Linked Data. 1. Introducción Los usuarios necesitan datos para desarrollar tareas asociadas a su trabajo. Estos datos están recogidos o agrupados en documentos, o que pueden ser obtenidos consultando bases de datos. Habitualmente estos datos son reutilizados en diferentes tareas por diferentes usuarios desde distintas aplicaciones. Por ejemplo, una historia clínica electrónica de un paciente puede ser usada (leída) por un médico para diagnosticar una enfermedad, o puede ser usada (actualizada) por un analista de un laboratorio para incluir los resultados de un análisis de sangre, o puede ser usada (leída y actualizada) por un enfermero para consultar el tratamiento que se le debe dar a un enfermo durante su hospitalización y apuntar los datos requeridos en el seguimiento. Cada uno de estos tres actores podría estar usando una aplicación diferente, pero todos ellos están trabajando sobre los datos relativos a un paciente, datos que en este Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 92 caso están agrupados en un documento conocido como “historia clínica electrónica de un paciente”, y que va evolucionando con la vida del paciente. Para tener éxito en sus respectivas tareas, estos actores necesitan que los datos contenidos en los documentos tengan niveles adecuados de calidad: precisamente en el ejemplo propuesto, cualquier error derivado de una decisión errónea puede ser crítico para el paciente. Se dice que los datos tienen calidad si sirven para el propósito (tarea) para el que se pretenden usar [1]. Esta definición de calidad de datos basada en fitness for use pretende ser más general que la percepción habitual de que los datos son de calidad si no tienen defectos. Esta definición conlleva dos implicaciones importantes: por un lado está la percepción multidimensional del problema (es necesario evaluar la calidad de los datos contenidos en un documento usando distintos criterios, a los que como se verá en la sección 2, se les denominan dimensiones de calidad de datos), y por otro lado se incluye el carácter subjetivo de la calidad de datos (cada uno de los actores anteriores, médicos, analistas de laboratorio, enfermeros, … puede tener una percepción diferente del nivel de calidad, incluso para la misma dimensión de calidad de datos). Como puede entenderse, estas dos implicaciones son más difíciles de gestionar que la percepción de que los datos tengan “cero defectos”. De estas dos implicaciones, se puede deducir que estimar cada una de las dimensiones de calidad requeridas no es tarea fácil. Una forma de realizar esta estimación es mediante la definición de medidas capaces de cuantificar la calidad de cada dimensión. Para poder definir dichas medidas es preciso entender el contexto del usuario y lo que puede entender por el hecho de que los datos se ajusten a su uso. En algunas ocasiones y para ciertas dimensiones de calidad de datos, puede ser posible establecer medidas objetivas (y repetibles) sobre los propios datos de manera independiente del contexto, mientas que en otras muchas, es necesario disponer de datos adicionales (normalmente denominados “metadatos” [2]) que de alguna forman representan el contexto de los usuarios. De hecho, podría decirse que estos datos adicionales permiten completar el significado del dato en el sentido marcado por la dimensión de calidad elegida. Así por ejemplo, para determinar el grado de actualidad (véase sección 2) de un valor en la bolsa es necesario adjuntar al dato correspondiente al valor del título una fecha que indique cuándo ha sido proporcionado; o por ejemplo, para determinar si una opinión en un foro merece ser tenida en cuenta (grado de reputación), un usuario debería poderse conocer quién dio esa opinión (seguramente el foro tenga establecido un sistema de clasificación de reputación de usuarios basado en la antigüedad de los usuarios, o en el número de opiniones proporcionada que son aceptadas como útiles por otros usuarios, …). En cualquier caso se hace imprescindible adjuntar y hacer persistentes dichos datos adicionales junto a los datos utilizados por los usuarios, de modo que las distintas aplicaciones puedan disponer de ellos para establecer sus propios métodos de medición. Es importante resaltar que este dato adicional no tiene por qué ser el valor de la medida en sí, o una anotación directa de calidad como proponen Price y Shanks en [3], sino que generalizando, podemos considerar que es un elemento que permitirá calcular la medida de calidad de datos para una determinada dimensión. La bibliografía recoge algunas formas de mantener estos vínculos, tales como la propuesta de Wang y Madnick para el modelo relacional en [2] o la de Caballero et al en [4] para documentos XML. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 93 Nuestra motivación inicial para esta investigación está basada en el hecho de que recientemente, en un proyecto de I+D relacionado con la gestión de historias clínicas electrónicas, nos planteábamos aplicar la propuesta presentada en [2] a una base de datos XML nativa, para optimizar, basándonos en la calidad de datos de los documentos usados, algunos de los procesos que se estaban ejecutando en un sistema de información relacionado con gestión sanitaria, y que ya estaba en producción. La idea era establecer los mecanismos adecuados para medir la calidad de los datos almacenados en dicha base de datos para proporcionar a los usuarios una estimación del nivel de calidad que tenían los datos, de modo que pudieran decidir si usarlos o no en función del nivel de calidad obtenido. Pero pronto nos dimos cuenta que esto implicaba modificar tanto el modelo de procesos como el modelo de datos del SI, pues teníamos que almacenar los datos adicionales y agregar las consultas correspondientes. Tras inspeccionar algunas alternativas, llegamos a la conclusión de que estando el sistema en producción no podíamos hacer las modificaciones correspondientes, al menos las correspondientes al modelo de datos, pues implicaría hacer un mantenimiento adaptativo del resto de la aplicación, extremo que la empresa que ejecutaba el software no se podía permitir. Además surgió otro inconveniente: de hacerlo así, los datos sólo estarían disponibles para una determinada aplicación, y sería muy complicado integrar los resultados en otras aplicaciones, por lo que podía no ser una propuesta suficientemente viable. Tras inspeccionar los trabajos propuestos por Missier et al en [5] o Stivilia et al en [6] basados en la aplicación de tecnologías semánticas para gestionar aspectos de calidad de datos, llegamos a la conclusión de que la solución pasaba por crear una capa adicional que permitiese gestionar los aspectos relacionados con la medición de la calidad de los datos, y que además permitiera tenerlos disponibles para distintas aplicaciones. En este artículo presentamos una parte de los avances que hemos ido haciendo al crear tanto la capa, a la que hemos llamado mapas de agregación, como los aspectos tecnológicos asociados. El resto del artículo está estructurado como sigue: en la sección 2 se presenta los conceptos relevantes relacionados con calidad de datos que debemos tener en cuenta para esta gestión. En la sección 3 presentamos los fundamentos de los mapas de agregación, y finalmente, en la sección 4 presentamos algunas conclusiones y líneas de trabajo futuro. 2. Conceptos de Calidad de Datos Existen numerosas definiciones del concepto de calidad de datos, pero la más aceptada es sin duda aquella basada en la idea de fitness for use [7]. Siguiendo esta definición, una de las estrategias más comunes para afrontar el estudio de la calidad de datos (en adelante DQ, de las siglas en inglés Data Quality, por simplificar) consiste en descomponer la percepción global de calidad de datos de un conjunto de datos en una serie de “subcalidades” denominadas dimensiones de DQ [7], (al estilo de lo que hace la ISO 9126 [8] para el software) y establecer determinados criterios de aceptación para cada una de ellas. Estos criterios de aceptación deben estar definidos Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 94 en función de los posibles rangos de los resultados de medición. Así, si tras medir el nivel de calidad según cada una de las dimensiones de DQ del documento, se obtienen resultados fuera de los rangos de aceptación preestablecidos, entonces el documento podría considerarse como “defectuoso” y, por tanto, podría considerarse el no usarlo para la tarea, o al menos saber que se puede estar cometiendo un error al usarlo. La situación deseable es que existiese un sistema de medición integrado en el sistema de información que fuera capaz de identificar esos datos o documentos “defectuosos” y recomendar al usuario, al menos, su “no utilización”. Al conjunto de dimensiones de DQ que se utiliza en un contexto determinado para determinar el nivel de DQ de un documento se le denomina modelo de DQ. Para cada contexto (entendiéndose como tal el ámbito de una tarea) es necesario identificar aquellas dimensiones que mejor representen los requisitos de DQ de los usuarios. La bibliografía muestra ejemplos de modelos de DQ específicos para ciertos contextos: hospitalarios y de salud [9], o web [10], por nombrar unos cuantos representativos. Así mismo es interesante mencionar que ISO, ha publicado recientemente el estándar ISO/IEC 25012 [11], como parte de la familia SQUARE y que dicho estándar propone un modelo genérico de DQ para Sistemas de Información. En cualquier caso, el modelo que más se viene utilizando es el propuesto por Strong et al. en [1]. Estos autores agrupan las dimensiones DQ en cuatro categorías, que hacen referencia a los puntos de vista desde los cuales es posible evaluar la calidad de los datos (Tabla 1). Categoría Descripción Intrínseca de DQ Con dimensiones como precisión, objetividad, credibilidad, y reputación. Se refiere a la calidad que tienen los datos por sí mismos; Accesibilidad de DQ Con dimensiones como accesibilidad, seguridad en el acceso. Están orientadas a determinar si el alcance de los mecanismos de seguridad es suficiente como para poder acceder a los datos en condiciones de poder ser usados adecuadamente Contextual DQ Que engloba dimensiones como relevancia, valor añadido, actualidad, compleción, cantidad apropiada de datos. Estas dimensiones se refieren al alcance en que los datos pueden ser usados en un contexto determinado. Representacional de DQ Que engloba dimensiones como interpretabilidad, facilidad de compresión, grado de representación concisa, grado de representación consistente. Estas dimensiones se orientan a determinar si la forma en la que se representan y/o transmiten los datos les hace o no usables. Tabla 1. Categorías de dimensiones definidas por Strong et al en [1] . Una definición más completa del significado de estas dimensiones, asumiendo la posibilidad de la dependencia del contexto, puede encontrarse en distintos trabajos en la bibliografía, aunque los más interesantes son, a nuestro juicio, aquellos presentados en [7, 12, 13]. Siguiendo con el proceso de evaluación, el siguiente paso es definir propiamente cómo medir la DQ de los datos para cada una de estas dimensiones. Dado el gran número de propuestas en la bibliografía relacionadas con los aspectos de medición de datos, para una mejor comprensión se recomienda seguir la nomenclatura basada en ISO/IEC 15939 proporcionada por Caballero et al. en [4]. En este trabajo se intenta unificar las diferentes terminologías referidas a la medición de DQ encontradas en la literatura. Además destaca la existencia de tres tipos de medidas: las medidas base (que requieren un método de medición), las derivadas (que requieren una función de cálculo) y los indicadores (que requieren de un modelo de análisis y de un criterio de decisión). En la bibliografía [7, 12], se suele recoger una función de medición basada Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 95 en el porcentaje (ratio) de unidades de datos que satisfacen o no un criterio, tal y como está representado en la Figura 1. En base a esta fórmula se suelen definir la mayoría de las funciones de medición de DQ. Figura 1. Una Función de Medición de Calidad de Datos. En la fórmula de la Figura 1, se pueden apreciar dos medidas base: NúmeroDeUnidadesDeDatosQueSatisfacenUnCriterio y NúmeroTotalDeUnidades- DeDatos. El método de medición de ambas consiste en un conteo del número de unidades. Si para la segunda no hay mayor complicación que contar (por ejemplo, con un select count(*) from NombreTabla en SQL), para la primera aparece el problema de expresar, usando la tecnología asociada al sistema de información, si se cumple o no el criterio. Un criterio se puede definir como una regla de negocio que define cuándo un dato es válido desde el punto de vista del negocio (tanto de la semántica como de la sintaxis). Según Loshin en [14], esta regla de negocio puede recoger parte del know-how empresarial (por ejemplo los sueldos de los trabajadores según sus categorías), la legislación relacionada (como por ejemplo, edades legales para trabajar), u otros aspectos [13, 15, 16]. En cualquier caso, el resultado de decidir si una unidad de datos satisface un criterio puede ser por simplicidad “Verdadero” o “Falso”, aunque en algunas otras ocasiones es posible permitir distintas gradaciones del nivel de cumplimiento (“Mucho”, “Normal/Suficiente”, “Nada”). Usando la formulación más sencilla, y a fin de obtener un valor para una determinada medida, hay que contar cuántas unidades de datos obtienen un resultado de “Verdadero” en la prueba de no satisface un criterio. En entornos relacionales este conteo puede ser fácilmente resuelto introduciendo en la instrucción de consulta la cláusula where, siempre que sea factible representar así la condición del criterio: por ejemplo contar el número de valores nulos para la dimensión de compleción, o que el valor del dato pertenezca a un dominio definido como parte de la base de datos (en el caso de que el sistema gestor de bases de datos permitiera definir dominios), o bien en el caso de que el dominio se pudiera definir como un conjunto de valores almacenados en otra tabla y relacionados mediante integridad referencial: si está adecuadamente implementado, un intento de inserción de valores que violase el dominio generaría el correspondiente error, como es sabido. En estos casos los criterios pueden ser establecidos objetivamente e independientemente de cualquier otra evidencia. Como se dijo anteriormente, para evaluar algunas dimensiones de calidad de datos se requiere la emisión de un juicio, individual o colectivo, sobre el valor del dato. Pero muchas veces el dato por sí mismo no aporta suficiente información para emitir dicho juicio, sino que es necesario hacerlo sobre un dato adicional (en [5] son llamados “evidencias”) que completa el significado del dato en la dirección de la dimensión que se pretende evaluar. Este dato de juicio puede ser objetivo o subjetivo y se puede realizar sobre datos adicionales proporcionados de manera también objetiva o subjetiva. La Tabla 2, recogida en [4], muestra algunos ejemplos de escenarios donde se emiten juicios objetivos o subjetivos teniendo en cuenta datos adicionales proporcionados. sDeDatoslDeUnidadeNúmeroTota CriteriotisfacenUntosQueNoSaidadesDeDaNúmeroDeUn DQMedida  1 Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 96 Juicio Objetivo Juicio Subjetivo Valores Objetivos El estudio de la actualidad de una oferta de trabajo publicada en Internet con una fecha de inicio y otra fecha de final de validez. El portal Web debería proporcionar ambas fechas a los usuarios, de modo que puedan hacer un juicio basándose en evidencias objetivas al comparar la actualidad de la oferta con la fecha actual. El estudio del Valor Añadido de un dato: Alguien interesado en una cámara digital con zoom óptico mira las especificaciones técnicas del producto que busca para saber si el fabricante proporciona además información sobre el sistema de alimentación (pilas o baterías). Si lo encuentra el usuario debe decidir si los datos proporcionados hacen mejor o no la información que tiene sobre la cámara. Valores Subjetivos En el estudio de la reputación: Alguien está interesado en ver una película y busca críticas en internet o en un periódico. Puede tener más ganas de ver la película o perder el interés en ella, si la crítica que encuentra está hecha por alguien que se considera que tiene siempre un buen criterio a la hora de hacer las críticas. El estudio de la credibilidad de una noticia publicada en un periódico y que ha sido proporcionada por una agencia de noticias. Si alguien tiene prejuicios de que las noticias publicadas por ese periódico defienden unas determinadas ideas políticas, en caso de tener ideas distintas podría no creer las noticias publicadas, o en caso contrario creer la mayoría de ellas. Tabla 2. Ejemplos de tipos de escenarios donde la calidad de los datos se mide en función de datos adicionales proporcionados [4]. De todos modos, se requiere tener tanto el o los datos adicionales necesarios, almacenados y enlazados convenientemente junto con el dato cuya calidad se pretende evaluar y con la correspondiente regla de negocio. Como puede apreciarse, la dificultad está en mantener esta infraestructura, y es incluso más complicado para aplicaciones ya desarrolladas. Se necesita por tanto describir y almacenar adecuadamente la regla de negocio para poder reutilizarla después para otras instancias del proceso de medición, bien dentro de la misma aplicación, bien como parte de otras aplicaciones. En cualquier caso, es patente la necesidad de modificar tanto el modelo de datos como el modelo de negocio de la aplicación. Este paso depende obviamente de la tecnología usada en el desarrollo de la aplicación: sistemas gestores de bases de datos (SGBD) más o menos avanzados cuentan con lenguajes procedimentales embebidos, PLSQL o TransactSQL, para acometer estas tareas, pero no todas las empresas pueden tener o tienen posibilidad de utilizar estos SGBDR. Además nuevos modelos de negocio demandan el uso de otras tecnologías y arquitecturas que permitan el acceso remoto a través de mecanismos bien definidos y asequibles como puede ser http. Precisamente, este va a ser uno de los muros que tenemos que superar en nuestra propuesta. Otra dificultad añadida es la forma de operar con los resultados obtenidos de los procesos individuales de medición para cada una de las dimensiones: si todos los procesos de medición proporcionan como resultado medidas expresadas en la misma escala numérica (típica y preferiblemente en formato ratio como se describió anteriormente), entonces la evaluación de un dato se hace mediante una media ponderada entre las dimensiones y los resultados de la medición [12, 17], aunque no debe descartarse el uso de etiquetas lingüísticas, que necesitan de operadores específicos para obtener un resultado agregado de todas ellas [18, 19]. Es importante destacar que normalmente, y en aras de la simplicidad, los modelos de calidad de datos dan la misma importancia (peso) a todas las dimensiones de calidad que la Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 97 componen. Pero, como Wang y Strong demostraron en [20], no todas estas dimensiones son igualmente importantes como queda demostrado en [17], por lo que puede ser necesario hacer previamente una estimación del peso o importancia que se debe asignar a cada una de las dimensiones. 3. Una Arquitectura Software para gestionar mediciones de DQ Volviendo al problema que motivó esta línea de investigación y teniendo en cuenta los contenidos presentados en la sección segunda, en este apartado queremos introducir brevemente una primera aproximación a la solución. Básicamente nuestra propuesta consiste en una arquitectura consistente en dos capas: una que complementa al modelo de datos y otra que complementa al modelo de procesos del Sistema de Información. Por razones de eficiencia, diseño y seguridad es un complemento no invasivo es decir, en la medida de lo posible, no debe modificar ninguna de ellas. La capa de datos, a la que llamamos mapas de agregación, tiene como objetivo recoger los datos adicionales necesarios para la evaluación. Además de la necesidad de que los datos estén suficientemente auto-descritos, debemos tener en cuenta el requisito tecnológico de la interoperabilidad semántica. Por todo ello pensamos en el uso de tecnologías semánticas ya que permiten un descubrimiento más efectivo, la automatización e integración así como la reutilización de los datos entre distintas aplicaciones [21]. Además de satisfacer los requisitos, aportarían valor añadido a nuestra solución, como la posibilidad de disponer de espacios de anotación coherentes con el espacio de datos. Por su parte, la capa que complementa al modelo de procesos, a la que llamamos Capa de Gestión de Lógica de DQ, debería englobar tanto los procesos técnicos relacionados con la adquisición y mantenimiento de estos datos adicionales, las correspondientes reglas de negocio, y su ligadura a los datos almacenados en las bases de datos organizacionales, como aquellos procesos de gestión orientados a la computación y cálculo de los niveles de calidad de datos de los datos basados en la reglas de negocio. Además también existiría la posibilidad de extrapolar medidas en contextos similares usando razonadores, establecer mecanismos de recomendación de documentos, y la posibilidad de optimizar ciertos procesos típicos del sistema de información atendiendo a criterios de calidad de datos, como puede ser la búsqueda y recuperación de información filtrando aquellos documentos (o conjunto de datos) cuyos niveles de calidad no alcancen los mínimos deseables. A fin de modelar adecuadamente esta arquitectura software, son varias las tareas que tenemos que acometer: (1) identificar claramente qué datos están afectados por los requisitos de calidad de datos, (2) identificar cuáles son las dimensiones de calidad más adecuadas para los datos y cómo identificar los datos adicionales; (3) definir cómo conseguir valores para los datos adicionales y cómo anotarlos, y finalmente (4) identificar cómo calcular las evaluaciones de calidad de acuerdo a la percepción de DQ de diferentes grupos de agentes usando los modelos de calidad de datos proporcionados. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 98 3. HCCAC multiagent system. HCCAC can be defined by the need to control various devices and gather user information in a non-intrusive and automatic way within Context-Aware environments [5]. Additionally, HCCAC brings greater speed to the gathering, processing and storage of data, variety in the communication channels among system players, and security in the management of access and administration of information. Each of these characteristics allows users to feel safe within the context knowing that they are being monitored and that any type of unexpected incident can be prevented. Additionally, the variety of communication channels also facilitates the administration of the system and the interaction between the components within the environment. The HCCAC system also facilitates the integration and management of agents and devices. Communication between platform agents follows the standard FIPA ACL [8] (Agent Communication Language) specification. Communication protocol between agents and services is based on the SOAP [9] standard. The services that the agents invoke can be of two types: services that capture information from the context data that are obtained by the autonomous components; and services that function within devices installed in the context. All of this allows HCCAC to be a system that is easy to implement in complex environments and is not platform specific. HCCAC makes it possible to automatically obtain information on users, their actions and environment in a distributed manner. HCCAC primarily focuses on monitoring a person in their home and sending notifications on the state of the individual or possible incidents. Additionally, it combines the management of personal information with a model of daily activities that are developed by using the data provided by the sensors through the household network. The interpretation and reasoning of the base knowledge and the daily activity models developed by the system provide an added value to the system. HCCAC makes is possible to easily use and share context-aware applications within changing physical spaces. As seen in Figure 1, the system is composed of the following agents: - Provider agents capture and summarize the data obtained by both internal and external heterogeneous context sources so that the Interpreter and Database agents can process and reuse these data. The system is dynamic and is capable of incorporating an information Provider agent at any given moment by adding the corresponding sensor or capturing the necessary information from a server or external provider. - Database agents store the context data obtained by the Provider agents. The organization of this information is similar for different environments. This agent is in charge of managing and exploiting the stored data. Additionally it provides the necessary information to the interpreter agent and records and updates the action plans that are determined by the interpreter agent. - Interpreter agent provides logical reasoning services to process the contextual information. The interpreter agent reasons out the actions that must be taken by creating a plan that determines the optimal course of action for reaching an objective. This agent provides the ability to reach high level Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 105 and complex objectives and avoids errors that could result in inefficacies. It also allows for greater flexibility when dealing with new objectives. - Resource Identification Agent (LcA) makes it possible for the provider agent and the interpreter agent to work directly with the applications and the users in order to avoid dangerous situations or particular incidents with the user. This agent is in charge of maintaining a record of the provider agents that are active in the system, in addition to allowing or denying the inclusion of new provider agents. Fig. 1. Overview of the multi-agent system HCCAC. Context-aware applications in HCCAC also check the information available from the context providers and are in constant listening mode to deal with possible events that the context providers transmit. The applications use different levels of context information and adapt their behavior according to the active context. They check the functionalities registered in the system and have a location for all of the context providers made available within the environment. One way of developing context-aware applications is to specify actions that respond to changes in the context under specific conditions and rules. The agents described function independently from the platform on which they are installed. The external provider agents obtain context information through external resources such as, for example, a server that provides meteorological information about the weather in a specific place, or a location server that provides information on the location of a person who is not at home. The internal provider agents gather information directly from the sensors installed within the environment, such as RFID based location sensors installed in the home of a patient, or light sensors. The functions of the interpreter agent include both processing information provided by the database agent, and reasoning out the information that has been processed. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 106 The interpreter agent offers context data of high level interpretation to both the context-aware applications and the devices in which it acts, from low-level context data. Context-aware applications use different levels of context information and can adapt their performance according to the context within which they are executed. After consulting the data registered by the LcA, these applications can locate the web services handled by the context providers. Context provider agents facilitate the access of the applications and web services that provide information to the system. For example, web applications provide meteorological data to the HCCAC system. In order to obtain context data, context-aware applications can ask the Provider agent or wait for an event from the Provider agent. LcA allows users and agents to locate different context applications. LcA controls large areas where there are context providers that can be located in internal or external networks. The LcA searches and adapts to the changes that are introduced within the context when adding or deleting physical sensors or reconfiguring the actual devices. It also unfolds a mechanism that allows context providers to notify about their functionalities within the LcA. 4. Using context-aware computing to apply patient control. Our case study developed prototype for improving the quality of life for a patient living at home. The system gathers information from the sensors that capture data and interact with the context. The primary information gathered by the sensors that have been installed is the location-aware for the user in the environment. The system also processes information relative to the temperature in the different rooms of the patient’s home, and the lighting conditions in the areas where the user moves about. All of the access doors in the house have an automatic open and close mechanism. The house was installed with (i) passive infrared motion detectors on the ceiling and (ii) automatic door opening mechanisms. The motion detectors and door opening mechanisms, interact with the microchip Java Card & RFID [11] users to offer services in run time. Each dependent user is identified by a (iii) Sokymat ID bracelet Band Unique Q5 that has an antenna and a RFID-Java- Crypto-Card chip with a 32K Module and Crypto-CoProzessor (1024 bit RSA) compatible with the SUNs JavaCard 2.1.1 [20]. También se instalan (iv) sensores de luminosidad, que se utilizan para gestionar el nivel de luminosidad de una estancia haciendo que se mantenga entre unos valores pre-asignados modificables, (v) una pantalla TFT de superficie, que permite visualizar y gestionar los elementos principales del sistema. There were also light sensors (iv) installed to manage the level of lighting in the home, maintaining the level within a pre-determined set of values, (v) a TFT surface screen that makes it possible to see and manage the principal elements of the system. The sensors or actuators are placed in strategic positions within the home. All of these devices are controlled by agents. The sensors network is responsible for generating alarms after comparing the user’s current state with the parameters of the user’s daily routine, which has been stored in the system. The system can generate alarms if it recognizes a significant change Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 107 within the parameters of the user’s stored daily routine, such as if the user gets up prior to a specific hour on a non-work day, if the use spends more time than normal standing at a door without entering, or if the user remains motionless in the hallway for an extended period of time. The main idea, which can be considered the core of the case study, is the system’s ability to hide the available technological resources from the patient, ensuring that they remain concealed from the patient’s daily life activities. In this way, users have only to be concerned with informing the system of their preferred living conditions and the system itself takes care of managing the resources and acting accordingly. It is necessary to apply or develop an appropriate analysis and design methodology, and to develop an organizational structure. The first step, however, is to analyze the extent of the system’s performance as it is installed in the patient’s home. Fig. 2. Diagram of the different types of Interpreter Agents The agent on which the HCCAC system is based is the Interpreter Agent. The diagram in Figure 2 shows the different types of Interpreter Agent, which involve a variety of roles or capacities: (i) RoleFind, assigns a role or finds a valid role for a user based on the identification of the user and the data assigned to him or her; (ii) DataFind, obtains information associated with a user; (iii) DataReasoning, detects any problem and the information associated with a user, evaluate the information and determines a solution to the problem; (iv) SolutionEvaluate, evaluates and transmites the result of a solution; (v) SolutionCheck, checks the solution and gives an assessment; and (vi) SolutionAssign, assings a solution to a user. The Interpreter agent can also initiate a series of services: (i) DirectAction, executions an action for a user; (ii) CommunicationAction, communicates an action that must be taken by a user; (iii) ServiceTask, initiates a task in the system; and (iv) GenerateEvent, generates an event after calculating or evaluating the data. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 108 The interaction between agents and the sensors installed in the home for the prototype presented in this paper can be described by using an example, as shown in Figure 3, where the internal Provider Agent (Situ Ag) executes web services to send signals to the sensors, and communicates with the Interpreter agent to inform it of the user’s situation. Situ Ag also receives signals from the Interpreter Agent in order to, for example, allow or prohibit user access to controlled areas. The LcA agent registers each of the services offered by the Situ Ag. The LcA agent continually updates the list of services provided by the Situ Ag so that it can be transferred through web services to the active applications in the context. Furthermore, the Database Agent manages the context information based on the data provided by the Interpreter Agent. Fig. 3. Ejemplo de interacción entre agentes, recursos y aplicaciones Context-Aware. It is also important to consider the transformation of the information that is produced within the system. First of all the system gathers data from the components of the context, which is then stored in the information system. Information on the context is taken from these data and subsequently reasoned out. To do so, the agents use case based reasoning (CBR) in a computational environment with intelligent processing capability. The CBR systems use the experience from similar previous situations in order to solve a new problem. This makes it possible to personalize the context of any accounting for user data and preferences that are pertinent to similar previous cases. The information Provider agents work together with the Interpreter agent to carry out this task. 5 Results and Conclusions. HCCAC was used to develop a prototype used in the home of a dependent person. It incorporates JavaCard technology to identify and control access, with an added Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 109 value of RFID technology. The integration of these technologies makes the system capable of automatically sensing stimuli in the environment in execution time. As such, it is possible to customize the system performance, adjusting it to the characteristics and needs of the context for any given situation. Different studies related to context-aware systems, such as [11] [6] [13] [16], focus exclusively on gathering positional data on the user. The authors of these papers gather the positional data on the users through GSP signals, mobile telephone towers, proximity detectors, cameras and magnetic card readers. Many of these signals work with a very wide positioning range, which makes it difficult to determine the exact position of the user. In contrast, the system presented in this paper determines the exact position of the user with a high level of accuracy. To do so, the system uses JavaCard and RFID microchip located on the users and in the sensors that detect these microchips in their context. Others studies, such as [14], in addition to locating the users in their context, try to improve the communication between patients and medical personnel in a hospital center by capturing context attributes such as weather, the state of the patient or role of the user. In addition to capturing information from various context attributes such as location, temperature and lighting, HCCAC also incorporates the Interpreter agent reasoning process to provide services proactively to the user within a Home Care environment. HCCAC incorporates new information Provider agents in execution time. In this respect, HCCAC proposes a model that goes one step further in context-aware system design and provides characteristics that make it easily adaptable to a home care environment. Although there still remains much work to be done, the system prototype that we have developed improves home security for dependent persons by using supervision and alert devices. It also provides additional services that react automatically in emergency situations. As a result, HCCAC creates a context-aware system that facilitates the development of intelligent distributed systems and renders services to dependent persons in their home by automating certain supervision tasks and improving quality of life for these individuals. The use of a multiagent system, web services, RFID technology, JavaCard and mobile devices provides a high level of interaction between care-givers and patients. Additionally, the correct use of mobile devices facilitates social interactions and knowledge transfer. Our future work will focus on obtaining a model to define the context, improving the proposed prototype when tested with different types of patients. Acknowledgements. This work was supported JCYL SA071A08 project. References 1. Abowd, G. D., Atkeson, C. G., Hong, J., Long, S., Kooper, R., and Pinkerton, M. (1997). Cyberguide: A mobile context-aware tour guide. Wirless Networks, 3(5). 2. Angulo, C., & Tellez, R. (2004). Distributed Intelligence for smart home appliances. Tendencias de la minería de datos en España. Red Española de Minería de Datos. Barcelona, España. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 110 3. Ardissono, L., Petrone, G. and Segnan, M. 2004. A conversational approach to the interaction with Web Services. Computational Intelligence, Blackwell Publishing. Vol. 20. pp. 693-709. 4. Bahadori, S., Cesta, A., Grisetti, G., Iocchi, L., Leone1, R., Nardi, D., Oddi, A., Pecora, F. & Rasconi, R. (2003). RoboCare: Pervasive Intelligence for the Domestic Care of the Elderly. In AI*IA Magazine Special Issue, January, 2003. 5. Brown, P. J. (1996). The stick-e document: A framework for creating context-aware applications. In Proceedings of the Electronic Publishing, Palo Alto, pages 259–272. 6. Burrell, J. and Gay, G. (2002). E-graffiti: evaluating real-world use of a context-aware system. Interacting with Computers – Special Issue on Universal Usability, 14(4):301– 312. 7. Cheverst, K., Davies, N., Mitchell, K., Friday, A., and Efstratiou, C. (2000). Developing a context-aware electronic tourist guide: some issues and experiences. In Proceedings of the SIGCHI conference on Human Factors in Computing Systems, pages 17–24, New York, NY, USA. ACM Press. 8. Corchado, J.M. , Bajo, J. , de Paz, Y. & Tapia, D. (2008). Intelligent Environment for Monitoring Alzheimer Patients, Agent Technology for Health Care. Decision Support Systems. ISSN 0167-9236.Vol 34 (2) pp. 382-396. 9. Corchado, J.M., Bajo, J. & Abraham, A. (2008). GERAmI: Improving the delivery of health care. IEEE Intelligent Systems. Special Issue on Ambient Intelligence - Mar/Apr 08. 10. Dey, A. K. (1998). Context-aware computing: The CyberDesk project. In Proceedings of the AAAI, Spring Symposium on Intelligent Environments, Menlo Park, CA. 11. Espinoza, F., Persson, P., Sandin, A., Nyström, H., Cacciatore, E., and Bylund, M. (2001). GeoNotes: Social and navigational aspects of location-based information systems. In Proceedings of the 3rd International Conference on Ubiquitous Computing, Atlanta, Georgia, USA, pages 2–17. 12. Hull, R., Neaves, P., and Bedford-Roberts, J. (1997). Towards situated computing. In Proceedings of the International Symposium on Wearable Computers. 13. Kerer, C., Dustdar, S., Jazayeri, M., Gomes, D., Szego, A., and Caja, J. A. B. (2004). Presence-aware infrastructure using web services and RFID technologies. In Proceedings of the 2nd European Workshop on Object Orientation and Web Services, Oslo, Norway. 14. Muñoz, M. A., Gonzalez, V. M., Rodriguez, M., and Favela, J. (2003). Supporting context-aware collaboration in a hospital: an ethnographic informed design. In Proceedings of Workshop on Artificial Intelligence, Information Access, and Mobile Computing 9th International Workshop on Groupware, CRIWG 2003, pp. 330–334. 15. Oren, E., Haller, A., Mesnage, C., Hauswirth, M., Heitmann, B., Decker, S.: A Flexible Integration Framework for Semantic Web 2.0 Applications. IEEE Software, vol. 24, no. 5, pp. 64-71, ( 2007) 16. Priyantha, N. B., Chakraborty, A., and Balakrishnan, H. (2000). The cricket locationsupport system. In Proceedings of the 6th Annual International Conference on Mobile Computing and Networking, pages 32–43. ACM Press. 17. Ryan, N., Pascoe, J., and Morse, D. (1997). Enhanced reality fieldwork: The contextaware archaeological assistent. Computer Applications in Archaeology. 18. Schilit, B. and Theimer, M. (1994). Disseminating active map information to mobile hosts. IEEE Network, 8(5):22–32. 20. Want, R., Hopper, A., Falcao, V., and Gibbons, J. (1992). The Active Badge Location System. ACM Transactions on Information Systems, 10(1):91–102. 21. ZhiqunChen (Sun Microsystems). Java Card Technology for Smart Cards. Addison Wesley Longman. ISBN 0201703297. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 111 Developing Advanced Services for SMEs using Service-Centric Tools: Experiences and Challenges Francisco J. Garijo1, Juan Pav´on2, Carlos Rodr´ıguez2, and Damiano Spina2 1Telef´onica I+D, Emilio Vargas 6, 28043 Madrid, Spain [email protected] 2Facultad de Inform´atica, Universidad Complutense de Madrid, Profesor Jos´e Garc´ıa Santesmases s/n, 28040 Madrid, Spain [email protected],[email protected], [email protected] Abstract. This paper presents the experiences and the results achieved for delivering sophisticated Business Support Systems to Small and Medium Enterprise (SMEs), using advanced service centric solutions developed in the SECSE project. The SECSE methodology provides concepts methods, processes, and techniques for developing service centric applications, and the supporting toolkit include tools for supporting the principal activities such as publication, discovery, execution, monitoring, and testing. The paper illustrates the use of the methodology for building a pilot, which delivers to SMEs integrated solutions including computing and communication infrastructure, and complex functionality such as CRM, Work-Flow processing, and logistics. Metrics and evaluation results for assessing both the technical benefits and the business benefits of the SECSE outcome are also described. 1 Introduction Materialization of the “service paradigm” which includes concepts like Service Oriented Development, Service Oriented Architecture, Service Oriented Applications and others, call for the need of a joint effort between industry and academia to provide technology, methodology and supporting tools for building service systems, and making them accessible to users. The SECSE project [1] has faced this challenge by gathering IT companies, developers and research labs to find out new solutions for exploiting the full potential of software services and for providing a sound engineering framework for the creation of services and service-centric systems. The project has delivered two principal outcomes: A methodology providing a conceptual model, methods, processes, and techniques for developing service centric applications, and supporting tools including capabilities to describe, compose, discover, monitor and deliver services. Research results have been validated by Industrial partners exercising both the techniques and the Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 112 supporting tools for developing application pilots in Automotive and Telecommunication domains. Additional development experiences have been done integrating new services from each industrial partner, in order to set up a common experimental setting with which to assess technical and business benefits. Research effort lead by academic partners has been extensively described in different papers [9,10,11,12,8,5,14,7,16]. This paper focus on the industrial experiences and specifically in the experiences and the results achieved developing advances services for SMEs. The organization of the paper is the following. After this introduction, section 2 gives a brief outline of the SECSE methodology and the supporting toolkit. Section 3 presents the evaluation approach describing the Logistic4SME pilot, the evaluation process and metrics. The evaluation results are in section 4, and finally the Conclusions and open issues are summarized in section 5 2 The SECSE methodology and toolkit The Project has produced two principal outcomes: A methodology and supporting tools for developing service centric systems. The SECSE methodology provides a conceptual model including terminology, concepts and relationships for service engineering, methods, processes, and techniques for developing service centric applications. The functional areas are depicted in figure 1. –Service-centric System Engineering comprises the principal processes for building service-centric systems such as analysis, design, development, deployment and operation. SECSE provide specific subprocesses and supporting tools for design-time and runtime. –Service Engineering addresses development practices aiming to deliver atomic services. –Service Acquisition and Provisioning focus on process and tools for “service marketplace” actors such as service consumers, service providers and service brokers, to publish, negotiate, monitor, and deliver services. The SeCSE suite aims to support service stakeholders to apply the methodology for building and managing service-centric systems. The toolkit covers the entire life cycle including capabilities to describe, compose, discover, monitor and deliver services. 1. Service Discovery tools provide specialized support for finding services and approximate orchestration starting from business level UML use cases and captured requirements. The SECSE Tools are Early Service Discovery Suite ESD, Architecture Service Discovering (ASD) and Runtime Service Discovery (RSD). 2. Service Specification tools enhance standard service specification and exposition formalisms by means of facets [7] incorporating semantic descriptions. The SECSE Tool is Facet Management Tool. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 113 Fig. 1. SECSE Methodology (from [1]) 3. Service Publication tools allow service registration and exposition. The SECSE Tool is SeCSE Registry. 4. Service Testing tools test services to build a confidence in the service’s functional and non functional features. The SECSE Tools are Testing Facet Generator, Regression Testing Tool and Quality of Service Tool. 5. Service Monitoring aim to provide service-centric facilities for checking compliance with functional and non-functional requirements. The monitoring tools work both at process level (loose monitoring) and at single operation level (tight monitoring). The SECSE Tools are Tight Monitoring and Loose Monitoring. 6. Service Composition tools enhance standard BPEL[13] tools incorporating execution and monitoring rules. The SECSE Tool is Composition Designer. 7. Service Deployment and Execution tools execute enriched BPEL services by offering negotiation, binding and re-planning mechanisms as well as run-time service discovery. The SECSE Tools are Deployer and Runtime Execution engine. 3 A SECSE case study: Advanced Logistic Service for SMEs The SECSE project has developed several case studies for assesment of the SECSE methodology and tools [2,3]. One of them is the a Business Support Sys- Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 114 active participation in standard forums, and spending additional development effort to upgrade the prototypes into stable tools. References 1. A5.D4.2 SeCSE Methodology V1.3 .(http://secse.eng.it). 2. A6.D11 - CRF Automotive pilot development architecture (v2) (http://secse.eng.it). 3. A6.D12 - T-A Telecommunication pilot development architecture (V2) (http://secse.eng.it). 4. A6.D16 Testing and evaluation of web services for pilots. 5. F.J. Nieto, L. Bastida, M. Escalante, A. Gortazar.: “Development of Dynamic Composed Services based on the Context”. Proceedings of the 2nf International Conference Interoperability for Enterprise Software and Applications (I-ESA 2006), Bordeaux, France, March 2006. 6. Garijo, F J., Bravo S., Gonzalez, J. Bobadilla E. BOGAR LN: “An Agent Based Component Framework for Developing Multi-modal Services using Natural Language”. L.N.A. I, Vol. 3040. pp 207-. Springer-Verlag. 2004. 7. J. Walkerdine, J. Hutchinson, P. Sawyer, G—. Dobson, V. Onditi : “A Faceted Approach to Service Specification”, Proc. Second International Conference on Internet and Web Applications and Services (ICIW07), Mauritius, May 2007. IEEE Computer Society Press. 8. Kozlenkov A., Spanoudakis G., Zisman A., Fasoulas V., Sanchez Cid F.: “Architecture-driven Service Discovery for Service Centric Systems” Journal of Web Services Research, 4(2), pp. 81-112, 2007. 9. L. Baresi and S. Guinea. “Towards Dynamic Monitoring of WS-BPEL Processes”, Proceedings of the 3rd International Conference of Service-oriented Computing (ICSOC’05). Amsterdam, The Nederlands, 2005. Lecture Notes in Computer Science, Vol. 3826, pp. 269-282. 10. M. Colombo, E. Di Nitto, M. Mauri: SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules. ICSOC 2006: 191-202. 11. M. Di Penta, R. Esposito, M.L. Villani, Roberto Codato, M. Colombo, and E. Di Nitto. WS-Binder: “A Framework to enable Dynamic Binding of Composite Web Services”. In Proc. International Workshop on Service Oriented Software Engineering (IW-SOSE’06), pages 77-80, Shanghai, China, May. 2006. ACM. 12. M. Di Penta, G. Canfora, M. Bruno, G. Esposito, V. Mazza – “Search Based Testing of Service Level Agreements” to appear in proceedings of the Genetic and Computation Conference (GECCO 2007), July 2007, London, UK, ACM Press. 13. OASIS Web Services Business Process Execution Language Version 2.0 Committee Draft, 25 January 2007. 14. Spanoudakis G., Mahbub K., Zisman A.: “A Platform for Context Aware Runtime Web Service Discovery”, IEEE 2007 International Conference on Web Services (ICWS 2007), Salt Lake City, Utah, USA. 15. UDDI v3.0, OASIS Standard, February 2005, http://www.uddi.org 16. Zisman A. Mahbub K., Spanoudakis G.: “A Service Discovery Framework based on Linear Composition”, IEEE 2007 International Service Computing Conference, Salt Lake City, Utah, USA. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 6, 2009 ISSN 1988–3455 SISTEDES, 2009 121