Modelo ontologico de muebles

DESARROLLO DE UNA ONTOLOGÍA Y DE UN SISTEMA DE RECUPERACIÓN DE LA

INFORMACIÓN PARA EL SECTOR DEL MUEBLE Y AFINES

PROYECTO FIN DE CARRERA Julio 2009

Realizado por:

Mouna Ziouziou

Dirigido por: Dr. Javier Samper Zapater

II

A mis queridos padres y hermanos por el tiempo y los momentos que no pude pasar con ellos.

III

AGRADECIMIENTOS

Agradecer en primer lugar a Dios por darme fuerza y voluntad para seguir adelante en los momentos de desesperación. Y a mis padres por confiar en mí y apoyarme siempre.

Agradecer especialmente a Miguel Ángel Abián, ya no solo por su

gran ayuda, experiencia, dedicación e interés, sino también por su calidad como persona. Su apoyo, sin duda, ha sido esencial para la realización de este proyecto con éxito. Gracias Miguel Ángel.

A mi tutor, Javier Samper por su dedicación y su gran

experiencia, y por proporcionarme la ayuda necesaria para llevar a cabo este proyecto.

A María José Núñez por ofrecerme la idea y darme la

oportunidad de realizar este proyecto. A Javi Adel por su experiencia, la atención que me ha prestado y

su preocupación cuando le he necesitado. A mis amigos, José Carlos, Lamia, Jorge y Fathía por haber sido

mi familia aquí. Por escucharme y aguantarme en los momentos más difíciles. Os quiero.

A mis amigos de la residenicia: Susana, Armando, Murad, Cris,

etc. Por aquellos años tan especiales que hemos compartido. Os deseo mucha suerte en vuestras vidas.

Gracias a todos los que he nombrado y a los que no he podido

nombrar.

IV

V

ÍNDICE GENERAL

AGRADECIMIENTOS .......................................................................... III

0. RESUMEN ....................................................................................... XI

1. INTRODUCCIÓN ........................................................................ 2 1.1 INTRODUCCIÓN ...................................................................................................... ‐ 2 ‐ 1.2 MOTIVACIÓN ......................................................................................................... ‐ 4 ‐ 1.3 OBJETIVOS ............................................................................................................. ‐ 5 ‐

2. ESTADO DEL ARTE ................................................................... 6 2.1 NECESIDAD DE LA INTEROPERABILIDAD EN LA INDUSTRIA DEL MUEBLE Y AFINES .................... ‐ 6 ‐ 2.2 FUNSTEP ............................................................................................................ ‐ 10 ‐

2.2.1. El proyecto FunStep ................................................................................ ‐ 10 ‐ 2.2.2. El estándar ISO funStep .......................................................................... ‐ 11 ‐

2.2.2.1. La herramienta Cadef .................................................................... ‐ 13 ‐ 2.3 LA WEB SEMÁNTICA ............................................................................................ ‐ 15 ‐

2.3.1. Introducción a la Web de tercera generación ......................................... ‐ 15 ‐ 2.3.2. Descripción de la Web Semántica ........................................................... ‐ 16 ‐ 2.3.3. Representación del conocimiento ........................................................... ‐ 19 ‐ 2.3.4. XML: primer paso hacia la Web semántica ............................................ ‐ 21 ‐ 2.3.5. Ontologías ............................................................................................... ‐ 23 ‐ 2.3.5.1 Elementos de una ontología .......................................................... ‐ 25 ‐ 2.3.5.2 Tipos de Ontologías ....................................................................... ‐ 26 ‐ 2.3.5.3 Ontologías frente a Taxonomías ................................................... ‐ 27 ‐ 2.3.5.4 Lenguajes de ontologías ................................................................ ‐ 28 ‐ 2.3.5.5 Metodologías y librerías para construcción de ontologías .......... ‐ 35 ‐ 2.3.5.6 Herramientas para la construcción de Ontologías ....................... ‐ 40 ‐

2.3.6. Bases de Conocimiento frente a Bases de Datos .................................... ‐ 43 ‐ 2.3.7. Sistemas de almacenamiento ................................................................. ‐ 43 ‐ 2.3.8. Razonadores ........................................................................................... ‐ 44 ‐ 2.3.9. Lenguajes de consulta ............................................................................. ‐ 46 ‐

3. METODOLOGÍA Y PLAN DE TRABAJO ............................. 49 3.1. PLANIFICACIÓN Y GESTIÓN DEL PROYECTO ........................................................ ‐ 49 ‐

3.1.1. Definición de recursos ............................................................................. ‐ 50 ‐ 3.1.1.1 Recursos humanos ............................................................................ ‐ 50 ‐ 3.1.1.2 Recursos del entorno ........................................................................ ‐ 51 ‐

3.1.2. Planificación temporal ............................................................................ ‐ 51 ‐ 3.1.2.1 Diagrama de Gantt ............................................................................. ‐ 56 ‐

3.2. ESTIMACIÓN DE COSTES DEL PROYECTO ............................................................ ‐ 58 ‐ 3.2.1. Coste Laboral .......................................................................................... ‐ 58 ‐

3.2.1.1 Técnica basada en el proceso ........................................................... ‐ 59 ‐ 3.2.1.2 El modelo COCOMO 2 ........................................................................ ‐ 61 ‐

VI

4. PROCESO DE INGENIERÍA ................................................... 67 4.1 INTRODUCCIÓN .................................................................................................... ‐ 67 ‐ 4.2 ONTOLOGÍA FUNSTEP. CICLO DE VIDA. ....................................................................... ‐ 67 ‐

4.2.1. Especificación de Requisitos ................................................................... ‐ 68 ‐ 4.2.2. Análisis del Modelo de Datos funStep .................................................... ‐ 69 ‐ 4.2.3. Adquisición de Conocimientos ................................................................ ‐ 77 ‐ 4.2.4. Especificación de la Ontología ................................................................ ‐ 79 ‐ 4.2.5. Decisiones de diseño ............................................................................... ‐ 80 ‐ 4.2.6. Construcción de la Ontología .................................................................. ‐ 84 ‐

4.3 APLICACIÓN DE BÚSQUEDA WEB ............................................................................ ‐ 94 ‐ 4.3.1. FASE DE ANÁLISIS .................................................................................... ‐ 94 ‐

4.3.1.1. Especificación de requisitos ............................................................ ‐ 95 ‐ 4.3.1.2. Funcionalidades del sistema ............................................................. ‐ 97 ‐ 4.3.1.3. Casos de uso ...................................................................................... ‐ 98 ‐ 4.3.1.4. Diagramas de Actividad .................................................................. ‐ 102 ‐ 4.3.1.5. Análisis del interfaz de usuario ...................................................... ‐ 105 ‐

4.3.2. FASE DE DISEÑO .................................................................................... ‐ 106 ‐ 4.3.2.1. Diseño de la Aplicación ................................................................... ‐ 106 ‐ 4.3.2.2. Diseño de la Interfaz de Usuario .................................................... ‐ 112 ‐

5. IMPLEMENTACIÓN Y PRUEBAS ....................................... 115 5.1 FASE DE IMPLEMENTACIÓN .......................................................................... ‐ 115 ‐

5.1.1. Implantación de la Ontología en la Aplicación ..................................... ‐ 117 ‐ 5.1.2. Notas de implementación ..................................................................... ‐ 119 ‐

5.2 PRUEBAS Y EVALUACIÓN ............................................................................... ‐ 122 ‐ 5.2.1. Fundamentos de la prueba ................................................................... ‐ 122 ‐ 5.2.2. Pruebas del sistema .............................................................................. ‐ 122 ‐ 5.2.3. Pruebas de Consistencia en la Ontología .............................................. ‐ 136 ‐

6. CONCLUSIONES Y TRABAJO FUTURO ............................ 139 6.1. CONCLUSIONES ............................................................................................ ‐ 139 ‐ 6.2. TRABAJO FUTURO ........................................................................................ ‐ 141 ‐

BIBLIOGRAFÍA ............................................................................ 143

ANEXOS ......................................................................................... 145

VII

ÍNDICE DE FIGURAS Figura 2.1 Componentes de la interoperabilidad en una empresa ................................ - 8 - Figura 2.2 Captura de pantalla de la herramienta Cadef ............................................ - 13 - Figura 2.3 Captura del Cadef enlazando productos a la ontología ............................. - 14 - Figura 2.4 Mapa conceptual de la Web semántica (Rodríguez, 2005) ....................... - 17 - Figura 2.5 Esquema de la web semántica ................................................................... - 18 - Figura 2.6 Ejemplo de documento XML .................................................................... - 21 - Figura 2.7 Ejemplo de DTD del XML de la figura anterior ....................................... - 22 - Figura 2.8 Las ontologías establecen redes semánticas .............................................. - 24 - Figura 2.9 Diagrama de nodos y arcos. ...................................................................... - 31 - Figura 2.10 Representación de tripletas RDF. ............................................................ - 31 - Figura 2.12 Ingeniería y Adquisición Ontológica (Goble, 2002) ............................... - 38 - Figura 2.11 Actividades del ciclo de vida del desarrollo de una ontología ................ - 37 - Figura 2.13 El editor de ontologías Protégé-OWL. .................................................... - 41 - Figura 2.14 Ejemplo de OILed 3.4 ............................................................................. - 42 - Figura 2.15 Arquitectura de un Sistema Terminológico (Horrocks, 2001). ............... - 45 - Figura 3.1 Descomposición del proyecto en tareas .................................................... - 54 - Figura 3.2 Diagrama de Gantt .................................................................................... - 57 - Figura 4.1 Implantación actual de la herramienta Cadef. ........................................... - 69 - Figura 4.2 Estructura de un catálogo de datos ............................................................ - 70 - Figura 4.3 Asignación de propiedades ........................................................................ - 71 - Figura 4.4 Diagrama de información detallada sobre Organisation .......................... - 72 - Figura 4.5 Diagrama de Product_class y sus relaciones ............................................ - 73 - Figura 4.6 Ejemplo de configuración detallada de un producto ................................. - 74 - Figura 4.7 Ejemplo de propiedad dependiente de contexto........................................ - 76 - Figura 4.8 Ejemplo de propiedad independiente del contexto ................................... - 76 - Figura 4.9 Esquema de los conceptos mapeados a la ontología ................................. - 83 - Figura 4.10 Diferentes niveles de la taxonomía de muebles ...................................... - 85 - Figura 4.11 Jerarquía de Componentes de muebles ................................................... - 86 - Figura 4.12 Propiedades de PieceOfFurniture. Resaltada hasMaterial ..................... - 87 - Figura 4.13 Detalles de la propiedad hasMaterial ..................................................... - 88 - Figura 4.14 Propiedad de tipo Datatype ..................................................................... - 90 - Figura 4.15 Restricciones de las propiedades de Chair.............................................. - 91 - Figura 4.16 Restricción de tipo hasValue para la clase Sofa ...................................... - 93 - Figura 4.17 Diagrama de Casos de Uso. .................................................................... - 98 - Figura 4.18 Caso de uso Buscar Muebles detallado. .................................................. - 99 - Figura 4.19Caso de uso Buscar Composiciones detallado. ........................................ - 99 - Figura 4.20 Diagrama de Actividad – Especificar tipo mueble ................................ - 102 - Figura 4.21 Diagrama de Actividad – Realizar Búsqueda ........................................ - 103 - Figura 4.22 Diagrama de Actividad – Obtener detalles ............................................ - 104 - Figura 4.23 Vista de todos los objetos del sistema. .................................................. - 107 - Figura 4.24 Diagrama de clases de la aplicación...................................................... - 109 - Figura 4.25 Diagrama de Secuencia del escenario “Realizar Búsqueda” ................ - 110 - Figura 4.26 Diagrama de Secuencia del escenario “Obtener detalles” .................... - 111 - Figura 4.27 Interfaz de usuario ................................................................................. - 113 - Figura 5.1 Prueba – El usuario elige buscar Composiciones. .................................. - 123 - Figura 5.2 Prueba – El usuario elige buscar Camas Dobles. .................................... - 124 - Figura 5.3 Ejemplo de búsqueda de muebles de un Fabricante ................................ - 126 -

VIII

Figura 5.4 Ejemplo de búsqueda de Conjuntos de salón .......................................... - 127 - Figura 5.5 Ejemplo de búsqueda de Composiciones con camas .............................. - 128 - Figura 5.6 Ejemplo de búsqueda de camas individuales con cabecero .................... - 129 - Figura 5.7 Ejemplo de búsqueda de Sillas modenas en Valencia ciudad ................. - 130 - Figura 5.8 Ejemplo de búsqueda de Sillas con un rango de precio .......................... - 131 - Figura 5.9 Ejemplo de búsqueda de Mesas de salón cuadradas ............................... - 132 - Figura 5.10 Obtener detalles del producto “Bedroom Syros 2” ............................... - 133 - Figura 5.11 Obtener detalles del producto “Diez4 Single Bed” ............................... - 133 - Figura 5.12 Obtener detalles del producto “Carlotta Chair” ................................... - 134 - Figura 5.13 Obtener detalles del producto “Dubai Chair” ...................................... - 134 - Figura 5.14 Obtener detalles del producto “Javea Table 031” ................................ - 135 - Figura 5.15 Inconsistencias detectadas con Racer-Pro. ............................................ - 136 - Figura 5.16 Chequeo de consistencia de la ontología con RacerPro ........................ - 137 - Figura 6.1 Nueva implantación del Cadef (Versión beta). ....................................... - 142 -

IX

ÍNDICE DE TABLAS Tabla 3.1 Estimación de tiempos del proyecto ........................................................... - 55 - Tabla 3.2 Estimación de tiempos del proyecto ........................................................... - 55 - Tabla 3.3 Costes por hora de cada categoría .............................................................. - 59 - Tabla 3.4 Costes de personal ...................................................................................... - 59 - Tabla 3.5 Costes de material y equipo ........................................................................ - 60 - Tabla 3.6 Valores de los atributos y valores multiplicativos asociados ...................... - 65 - Tabla 4.1 Correspondencia de la Ontología con el modelo de datos .......................... - 75 -

X

XI

0. RESUMEN Este proyecto surge, en primer lugar, como iniciativa para promover el uso de un vocabulario común y unificado de términos que represente adecuadamente el significado (semántica) de los conceptos más usados en el sector del mueble y afines, con el objetivo de solventar el importante problema de la falta de interoperabilidad semántica que existe en esa industria. Este problema dificulta enormemente el intercambio de información entre fabricantes, distribuidores, comercios y clientes, y ralentiza el lanzamiento de nuevos productos al mercado. En segundo lugar, el proyecto surge para ofrecer una herramienta de búsqueda que facilite al usuario obtener información clara y precisa correspondiente a sus requisitos específicos de búsqueda (color del mueble, procedencia, dimensiones, precio, etc.). Algunos aspectos que describen los problemas actuales en cuanto a la búsqueda de información son:

Escasa precisión en los resultados. Algunas búsquedas generan decenas de miles de páginas que carecen de interés para el usuario; otras, por el contrario, no generan ninguna.

Alta sensibilidad al vocabulario empleado en la búsqueda. Si los documentos que realmente interesan no emplean exactamente el mismo vocabulario que la búsqueda, nunca aparecerán.

La herramienta de búsqueda implementada permitirá al usuario final encontrar

los muebles que busca; podrá especificar las características que desee y obtener información relevante sobre dichos muebles. Todo esto le permitirá, por ejemplo, comparar precios entre los distintos comercios y localizar física o virtualmente aquellos que le interesen. Para conseguir los objetivos marcados se han seguido las siguientes etapas: Construcción de una ontología cuyo dominio es la información sobre la industria

del mueble y afines. La ontología construida se ha basado en el estándar internacional de intercambio de información específico del sector del mueble funStep (ISO 10303-236).

Desarrollo de una base de conocimiento que almacene información sobre el

sector del mobiliario y afines (empresas, muebles, accesorios, telas, materiales, componentes, etc.) expresada en un lenguaje formal (OWL).

Desarrollo de una herramienta de búsqueda semántica que usará los conceptos

de la ontología y la información almacenada en la base de conocimiento. El lenguaje de búsqueda escogido ha sido SPARQL.

CAPITULO 1 - INTRODUCCIÓN

- 2 -

1. INTRODUCCIÓN

1.1 Introducción

El rápido desarrollo de la sociedad de la información y de sus tecnologías ha hecho posible la superación de retos como el almacenamiento de datos. La comunicación entre sistemas de información heterogéneos y distantes geográficamente es también otro problema resuelto gracias a Internet y a la universalidad de sus protocolos de comunicación. Con todo, aún existen algunos retos que superar. A saber: la búsqueda de información y su integración. El ejemplo más claro se encuentra en Internet. A pesar de la cantidad de información abrumadora en la red, no siempre el usuario encuentra lo que desea cuando emplea buscadores basados en palabras clave, y muchas veces tarda demasiado tiempo en encontrar la información deseada. Según muchos autores, la solución a estos radica en el uso de metadatos y ontologías. Los metadatos son datos que a su vez describen datos, y denotan cualquier tipo de información sobre la estructura y el contenido de un recurso, ya sea un documento HTML, una imagen, un documento de vídeo, un conjunto de datos o cualquier otro recurso. En el campo del almacenamiento y recuperación de la información, los metadatos permiten acceder más fácilmente a los recursos que los incluyen. Una de las facetas más interesantes de los metadatos es su utilidad para conseguir la interoperatividad entre diferentes sistemas de información, que pueden estar basados en distintas concepciones y tecnologías.

Los metadatos estructuran solamente los contenidos; las ontologías permiten estructurar la semántica (significado) de un recurso. Las ontologías establecen formalmente los conceptos de un cierto dominio –la palabra dominio denota un área específica de interés o un área de conocimiento– y sus relaciones, pudiendo ser compartidas por todos. Toda ontología representa cierta visión del mundo con respecto a un dominio. Su uso proporciona una forma de representar y compartir conocimiento haciendo uso de un vocabulario común e inambiguo.

Las ontologías favorecen la comunicación entre personas, organizaciones y

aplicaciones porque proporcionan una comprensión común de un dominio, de modo que se eliminan confusiones conceptuales y terminológicas. Favorecen también la comunicación entre aplicaciones y la comprensión común de la información entre ellas. Serán imprescindibles tanto en la Web semántica como en los futuros sistemas de gestión empresarial porque permitirán que las aplicaciones estén de acuerdo en los términos que usan cuando se comunican. Mediante ellas, será mucho más fácil recuperar información relacionada temáticamente. Empresas como Autonomy, FAST, Endeca y Newssift ya trabajan con herramientas semánticas para gestionar los datos incluidos en los centros de datos de grandes compañías y realizar búsquedas en ellos. Las ontologías sirven también para conseguir que los sistemas interoperen. Dos sistemas son interoperables si pueden trabajar conjuntamente de una forma


- 3 -

automática, sin esfuerzo por parte del usuario. El sector del mobiliario y afines (ámbito de este proyecto) se vio afectado por el problema de la falta de interoperabilidad, y en el año 1998 nació el proyecto funStep con los siguientes objetivos principales:

Generar un modelo de información común para el mueble. Desarrollar un método común para el intercambio de información

telemáticamente.

En definitiva, el proyecto funStep vino a mejorar la interoperabilidad (sintáctica) en el sector mobiliario, con las ventajas que ello conlleva: la interoperabilidad ayuda a las empresas a producir bienes y servicios más rápidamente y a un coste más reducido. Este proyecto culminó en el estándar internacional de intercambio de información del sector mobiliario: ISO 10303-236.

El departamento de Tecnologías de de Información (TI) de AIDIMA, empresa

donde se ha realizado este proyecto y una de las empresas colaboradoras en funStep, tuvo la iniciativa de ir más allá e intentar conseguir la interoperabilidad completa (sintáctica y semántica) entre las empresas del sector mobiliario. La falta de esta interoperabilidad en el comercio electrónico B2B produce grandes problemas, como por ejemplo la dificultad de comunicación entre empresas que definen de diferente manera objetos de negocio como “pedido” o “producto”; o la dificultad de realizar transacciones electrónicas dos empresas que entienden “precio” de distintas maneras (verbigracia, porque usan distintas monedas o porque una considera el IVA incluido en el precio y la otra no).

La construcción de una ontología que defina los conceptos relacionados con el

sector mobiliario, proporcionando así un vocabulario común, aumentaría la competitividad de las empresas, su flexibilidad y eficiencia. Y daría lugar a beneficios económicos tanto para las empresas como los consumidores.

Por ello, la primera meta de este proyecto es conseguir dicha ontología, que

permitirá catalogar la información mediante el significado de las palabras relacionadas con el sector en cuestión. Gracias al conocimiento almacenado en ella, las aplicaciones podrán extraer automáticamente o semiautomáticamente datos de las páginas web, procesarlos y realizar inferencias a partir de ellos, así como tomar decisiones y negociar con otros agentes o personas.

Otro de los problemas importantes en el sector mobiliario en cuanto a las TI, y

que puede mejorarse mucho con el uso de la ontología, es la búsqueda de información relacionada con los muebles y afines (telas, accesorios, materiales, etc.). A día de hoy existe en la web algún que otro buscador de comercios de muebles, fabricantes o proveedores y existen páginas web de algunos comercios y fabricantes donde en ocasiones aparecen expuestos sus productos. Sin embargo, no existe una herramienta que permita al usuario encontrar un mueble del tipo que quiera, con las características que desea, comparar precios de distintos comercios, consultar distintos catálogos y, sobre todo, obtener resultados exactos que se ajusten a sus necesidades, sin tener que perder mucho tiempo. Esto se puede conseguir empleando las tecnologías semánticas


- 4 -

disponibles en la actualidad (RDF(S), OWL, SPARQL, etc.) y haciendo uso de la ontología de mobiliario y afines creada. Con el fin de desarrollar una de las muchas posibles aplicaciones que ofrece la ontología (catalogación electrónica, integración automática de catálogos electrónicos de distintos fabricantes, anotación semántica de recursos relacionados con muebles, introducción de muebles y complementos en marketplaces, etc.), se establece como segunda meta para este proyecto final de carrera el desarrollo de un prototipo de buscador de información sobre muebles que utilice la ontología de mobiliario y afines para resolver una serie de consultas de gran interés para los usuarios. A diferencia de los buscadores convencionales, el nuevo buscador permite realizar consultas estructuradas; es decir, no basadas simplemente en la concordancia de una serie de palabras clave.

1.2 Motivación

La idea de realizar este proyecto surgió durante una entrevista que mantuve con la directora del departamento de Tecnologías de la Información (TI) de AIDIMA, Dña. María José Núñez, donde realicé prácticas en empresa durante el curso 2007/08. Este departamento ha participado en docenas de proyectos internacionales relacionados con las tecnologías de la información; y ha desarrollado y promueve funStep (ISO 10303-236), el estándar internacional en el sector del mueble para el intercambio de información en sistemas CAD.

En el momento de la entrevista quería comenzar mi proyecto final de carrera y me interesaba que estuviera relacionado con el uso de ontologías y búsquedas semánticas, pues lo considero un campo de la informática con mucho futuro. Este interés lo despertó en mí por primera vez el catedrático D. Gregorio Martín durante las clases de la asignatura TIC (Tecnologías de la Información y de la Comunicación). Posteriormente, adquirí unos conocimientos básicos sobre RDF y ontologías en la asignatura IST (Ingeniería de Servicios Telemáticos) que nos impartió el Dr. Javier Samper, experto en este campo y tutor de este proyecto final de carrera.

Cuando empecé a leer sobre Web Semántica, al igual que mucha gente, me pareció fascinante la idea de dotar a la web actual de inteligencia y expresar los datos de manera que sea comprensible para las máquinas, y que permita hacer deducciones automáticas a partir de ellos, consiguiendo así que las máquinas liberen a los humanos de muchas tareas tediosas. Durante aquella entrevista en AIDIMA la directora de TI me explicó que tuvieron una iniciativa hace unos 3 años, junto con otros centros colaboradores, de fomentar la utilización de un vocabulario común y unificado en la industria del mueble y afines. Para ello, se comenzó a construir una jerarquía que clasificara términos de muebles; pero esto se quedó solamente en documentos y hojas Excel, a medio hacer debido a la prioridad y urgencia de otros proyectos. En consecuencia, me ofreció la idea de construir una ontología que clasifique y defina formalmente los conceptos más usados del sector en cuestión, así como la de desarrollar un prototipo de buscador que utilice los conceptos de la ontología creada, para probarla y demostrar algunas de las funciones y posibilidades que tiene el uso de esta ontología. Para ello puso a mi disposición a D. Miguel Ángel Abián, investigador de AIDIMA con más de 14 años de experiencia en proyectos de I+D nacionales e internacionales.


- 5 -

Personalmente, me pareció muy interesante contribuir, aunque fuera en pequeña medida, al proyecto de la Web semántica, estableciendo semántica en un dominio como el del mobiliario y afines. Éste es un sector relevante y estratégico para la Comunidad Valenciana y carece de un vocabulario común, imprescindible para la catalogación de sus productos y para la interoperabilidad entre sus empresas.

1.3 Objetivos

El proyecto tiene unos objetivos bien definidos que son los siguientes: 1) Definir un vocabulario común, expresado formalmente, para representar

información relacionada con el sector del mobiliario y afines (telas, accesorios, materiales, etc.). Esto es, desarrollar una ontología que defina los conceptos más usados en la industria del mobiliario y afines, sus propiedades y las relaciones entre ellos. Esta ontología debe basarse en funStep, el estándar internacional de intercambio de información en sistema CAD.

2) Crear una base de conocimiento que almacene algunas instancias de muebles e información relacionada con el sector, con el fin de probar la ontología creada.

3) Desarrollar un prototipo de una aplicación web de búsqueda de muebles, basada

en tecnología semántica y que utilice los conceptos de la ontología y la información almacenada en la base de conocimiento para resolver consultas que sean del interés de los usuarios.

CAPITULO 2 – ESTADO DEL ARTE

- 6 -

2. ESTADO DEL ARTE

2.1 Necesidad de la interoperabilidad en la industria del mueble y afines

La interoperabilidad no es una palabra de moda: las sociedades industriales y

postindustriales deben su existencia a la interoperabilidad. El gran logro de Henry Ford consistió justamente en introducir un sistema donde las piezas se podían intercambiar y ensamblar de manera sencilla; es decir, un sistema de componentes interoperables. Antes de Ford las piezas se construían y se ensamblaban de manera personalizada para cada automóvil. Igualmente, el éxito de la industria electrónica y de la telefonía, sea móvil o fija, se deben a la interoperabilidad. En electrónica se pueden construir circuitos ensamblando componentes de distintos fabricantes, si uno se estropea puede cambiarse por un componente de otro fabricante. Y por último, en telefonía, redes telefónicas de países distintos, cada una con sus estándares y componentes telemáticos, interoperan para que personas separadas por miles de kilómetros puedan hablar. Para entender bien esto, veamos algunas definiciones de interoperabilidad:

La capacidad de dos entidades (típicamente aplicaciones de software) para cooperar intercambiando mensajes.

La capacidad de interpretar datos de manera uniforme (un comando

u orden es una clase particular de datos) a través de aplicaciones de software, a pesar de que éstas tengan diferentes sistemas de símbolos.

La capacidad para compartir e intercambiar datos que usan sintaxis y

semánticas comunes para encontrar una relación funcional de aplicación específica empleando un interfaz común.

Según la IEEE (Institute of Electrical and Electronics Engineers) la interoperabilidad es:

“La capacidad de dos o más sistemas o componentes para intercambiar información (interoperabilidad técnica y sintáctica) y usar la información que ha sido intercambiada (interoperabilidad semántica)”. Existen tres niveles de interoperabilidad, mencionados en el párrafo anterior (Abián, 2005):

Interoperabilidad técnica. Se refiere a la capacidad de dos sistemas informáticos (SI) de intercambiar señales. Exige una conexión física y un conjunto de protocolos de comunicación. Que dos SI interoperen técnicamente no significa que puedan intercambiar datos, pues para esto se precisa que los SI usen un mismo formato para el intercambio de datos.


- 7 -

Interoperabilidad sintáctica. Se refiere a la capacidad de los SI para leer los

datos procedentes de otros SI y obtener una representación que puedan usar. Es decir, en todos los SI involucrados, tanto la codificación de los datos como los protocolos de comunicación deben ser compatibles. Esto no implica que los SI procesen los datos de una manera consistente con su significado.

Interoperabilidad semántica. Es la capacidad de los SI de intercambiar la

información basándose en un común significado de los términos y expresiones que usan. Consideremos por ejemplo, dos SI en los que uno trabaja con facturas donde el campo “Importe” significa el “Importe de la factura en dólares”; y el otro, con facturas donde ese campo significa el “Importe de la factura en euros”. Evidentemente, ambos SI carecen de interoperabilidad semántica.

La interoperabilidad semántica no debe confundirse con la sintáctica: ésta se refiere a la dificultad de procesar automáticamente los datos, no a su “contenido”. Aquella se refiere a la dificultad de relacionar los términos desconocidos que aparecen en los datos con los ya conocidos o definidos. La interoperabilidad semántica no puede existir antes de la técnica y de la sintáctica.

La interoperabilidad es muy importante para las empresas porque ayuda a producir bienes y servicios más rápidamente, a coste más reducido, manteniendo los niveles de calidad y personalización más altos. Las empresas y organizaciones deben ser capaces de adaptarse a cambios del mercado por la externalización eficiente y estrategias de colaboración (Abián et al., 2004). A pesar de que muchas aplicaciones usen tecnologías unificadas (p.ej., XML para describir datos) los modelos de datos y de negocio permanecen heterogéneos. Incluso nociones muy comunes, como “pedido” o “cliente” pueden variar enormemente entre distintas aplicaciones. Esto significa que hay una falta de interoperabilidad semántica en el comercio electrónico B2B, que produce grandes problemas: ¿Cómo van a entenderse empresas que definen de manera distinta objetos de negocio como “pedido” o “producto”? ¿Cómo van a realizar transacciones electrónicas dos empresas que entienden “precio” de distintas maneras (una como la cantidad que figura en su catálogo; otra, como esa cantidad más impuestos y más gastos de envío)? Para conseguir la interoperabilidad se necesita integrar tres componentes temáticos (Vallespir et al., 2004):

Arquitecturas y plataformas para proporcionar la implementación de soluciones.

Un modelo de negocio para definir los requisitos de la interoperabilidad y apoyar la implementación de soluciones.

Ontologías para identificar semánticas de interoperabilidad en la empresa.


- 8 -

Los problemas derivados de la interoperabilidad provienen de los procesos necesarios para el intercambio de información electrónicamente. En general, las PYMES ven la interoperabilidad como una cuestión técnica y no como una capacidad (Magali et al., 2004).

Centrándonos en el sector del mobiliario, vamos a ver los problemas de la interoperabilidad relacionados con ontologías: Debido a que las PYMES no usan un vocabulario común, existe una falta de diccionarios de datos interoperables. Varias grandes organizaciones de estándares que han desarrollado los diccionarios de datos electrónicos han reconocido que una parte de la solución de este problema es la armonización entre los diccionarios internacionales disponibles. El primer paso para el intercambio de información entre los componentes económicos de las fronteras nacionales es la capacidad de utilizar la misma terminología. Hay una gran necesidad de transferir datos –diseños CAD, pedidos, albaranes, facturas, etc.- de forma estructurada entre fabricantes, distribuidores, clientes, etc. En la industria de diseño de interiores, hoy en día esto es casi imposible de hacer sin grandes inversiones por parte de cada uno de los fabricantes. La única manera de simplificar y hacer más eficiente este proceso es llegar a un acuerdo sobre una ontología común para los datos relacionados con el producto. Por ejemplo, la palabra «mueble» es aplicable a una gran variedad de productos con diferentes características. Para poder definir una “mesa de oficina ajustable eléctricamente” o una “cama de hospital”, se necesita poder seleccionar criterios para aparatos eléctricos. Y para ser capaces de definir mobiliario con componentes de iluminación, como muebles de baño con luminarias, debe poderse seleccionar criterios relativos a la iluminación.

Figura 2.1 Componentes de la interoperabilidad en una empresa


- 9 -

La parte principal de comunicación de datos sucede entre los productores y los minoristas, muchas veces con uno o varios agentes / distribuidores entre ellos. No basta encontrar una solución de la parte de recepción para los proveedores de mobiliario; los minoristas también reciben datos de los proveedores de componentes de iluminación, telas, etc. Otros receptores de información que necesitan manejar más información que los datos de muebles son los agentes de información de Internet, los desarrolladores de software, los arquitectos y diseñadores de interiores etc. En este sentido, la ontología debe ser capaz de manejar casi todos los productos manejados por los receptores de información. Algunos ejemplos:

Producto = Nombre usado para un producto de diseño de interior u exterior o parte de un producto que se vende como un producto por separado

Ejemplos de productos de diseño de interiores: Sofá-cama, mesa de

comedor, armario de cocina, mesa de oficina ajustable eléctricamente

Productos de diseño de exteriores: Banco, mesa de jardín, macetero, hamaca.

Partes de productos que se pueden vender como productos separados:

cabecero (para una cama), barra o palo (para una lámpara).

Productor = Nombre para el productor o fabricante de un producto. Finalmente, veamos algunos aspectos tenidos en cuenta en el trabajo de clasificación de la ontología objeto de este proyecto:

Las organizaciones relacionadas con la industria del mobiliario deberán clasificarse en diferentes categorías de empresas, como fabricante, distribuidor y minorista.

Se deben definir dimensiones y unidades que se utilizarán a la hora de transferir

datos de producción, de catálogos y de comercio electrónico. Los materiales usados en la industria del mueble se deben describir y agrupar en

diferentes clases. La existencia de una ontología del mueble permitirá, en principio, la interoperabilidad entre los SI de las empresas del mueble y afines, lo cual implica una serie de ventajas en cuanto a la competitividad de las empresas, flexibilidad, eficiencia, así como beneficios económicos, tanto para las empresas como los consumidores.


- 10 -

2.2 FunStep 2.2.1. El proyecto FunStep

El proyecto “funStep” surge debido a la necesidad que tienen los fabricantes y tiendas de mobiliario de intercambiar información de producto, tanto gráfica como textualmente independiente del sistema informático utilizado. En el mercado hay disponible una amplia oferta de sistemas de CAD especializados en la decoración de interiores, pero esos sistemas no permiten el intercambio de información entre ellos. Por otro lado, no existe una solución completa para la industria del mueble basada en EDI (Electronic Data Interchange). La mayoría de los fabricantes y sus clientes consideran esta incompatibilidad como el principal escollo para rentabilizar las inversiones, de forma que deciden retrasar la decisión, esperando a que se clarifique la situación del mercado. Como consecuencia, no mejoran la gestión de la información ni el servicio al cliente. Por otro lado, es necesario poder comprobar a priori la compatibilidad entre sistemas con el objetivo de evitar problemas a posteriori en el intercambio de información, que aparecerían en la relación diaria con el cliente. Debido a este importante problema industrial nació el proyecto funStep en 1998 con los siguientes objetivos:

Generación de un modelo de información común para el mueble. Desarrollo de los traductores necesarios para algunos sistemas CAD

comerciales, especializados en el mueble. Desarrollo de métodos de comprobación y certificación de programas CAD

conformes con el modelo funStep. Desarrollo de un método común para el intercambio de información vía

telemática. Demostración de la compatibilidad de sistemas CAD comerciales,

intercambiando información en un entorno industrial. En definitiva, funStep busca mejorar la interoperabilidad en el sector del mueble

y afines.

El impacto industrial que tiene el proyecto incide en dos grupos: fabricantes y comercios, y proveedores de sistemas. En cuanto a los fabricantes y comercios de mobiliario se presentan las siguientes ventajas:

Sistemas compatibles en el mercado. Aseguramiento de la inversión. Mejora del servicio al cliente. Reducción de la carga de trabajo no productivo. Apertura a la posibilidad del Comercio Electrónico. Reducción del tiempo de lanzamiento al mercado de nuevos productos.


- 11 -

Para los proveedores de sistemas, las ventajas son las siguientes:

Incremento del mercado real. Incremento de la confianza del cliente en el producto CAD. Los recursos de desarrollo pueden aplicarse a la mejora del producto,

liberándolos de la introducción de librerías de fabricantes. Una nueva funcionalidad en los paquetes: módulos para intercambio de datos

vía telecomunicaciones.

2.2.2. El estándar ISO funStep

FunStep es una iniciativa nacida en 1998 – como ya se ha mencionado anteriormente - alrededor de la ISO funStep, el estándar internacional para el intercambio de datos en las industrias del muebles y de diseño de interiores, formalmente conocida como la ISO 10303-236 " Sistemas de automatización industrial e integración - representación e intercambio de los datos de Producto - Parte 236: Protocolo de aplicación: Catálogo de muebles y diseño de interiores”.

Este estándar considera asuntos como: Product catalogue data (Información de productos de catálogo) Pricelists (Precios) Product Composition (Composición de productos) Product Breakdown (Desglose de producto) Properties (Propiedades) Parametric product configuration (parámetros de configuración de

productos) Multilingual data (Multilenguaje) Documentation assignment (asignación de documentación) Más.

El estándar interpreta la información de datos de producto (materiales, acabados,

medidas, especificaciones…). Estandariza los datos a intercambiar entre los distintos agentes de la cadena de valor (proveedores, fabricante, comercios) y también con los diseñadores y arquitectos.

Proporciona a través de un modelo de datos común, un mecanismo neutro capaz

de describir productos a través de su ciclo de vida: requisitos, tarifa técnica, diseño detallado, procesos de fabricación, escandallo, asociación con geometría, catalogación estructurada, gestión documental relacionada con pedidos, etc.

La información es representada en XML (eXtensible Markup Language),

facilitando el envío de los datos antes mencionados entre las diferentes compañías y los distintos sistemas informáticos. El modelo se describe también en diagramas UML (Unified Modeling Language) haciéndolo compatible con sistemas de bases de datos relacionales.

Las posibles aplicaciones del modelo de datos funStep son prácticamente


- 12 -

ilimitadas, pero algunos de los usos previstos inicialmente incluyen:

Distribución de información de catálogos de muebles desde una fuente única a varios portales web.

La combinación de datos de los catálogos de varias fuentes en un único sistema de gestión de venta al por menor.

La importación de especificaciones de componentes de múltiples proveedores en

un diseño de muebles o sistema de fabricación.

Generación de ventas de materiales en formato impreso y electrónico.

Intercambio y la reutilización de modelos de información gráfica.

Proporcionar datos de productos para el diseño de interiores y diseño de herramientas (por ejemplo, software de diseño de la cocina o el cuarto de baño).

El beneficio principal de la adopción del modelo de datos de la Norma ISO funStep es el aumento de la eficiencia que se deriva de compartir datos entre distintos sistemas informáticos, sin la necesidad de volver a introducir la información, reduciendo así las posibilidades de errores humanos y el tiempo de transacción de extremo a extremo. Para el desarrollo de nuevo software o nuevas aplicaciones web es posible reutilizar el modelo de datos funStep ya creado en lugar de gastar tiempo y esfuerzo en el desarrollo de una base de datos desde cero. Usar los sistemas del estándar ISO funStep significa que, por ejemplo, los proveedores de componentes puedan proporcionar la información técnica completa sobre sus productos a los fabricantes que, a su vez, pueden proporcionar información sobre los productos a los minoristas, publicar catálogos, operar con los sistemas de comercio electrónico, gestión de sistemas de control de existencias o el suministro de datos para el diseño de interiores, todo, sin la necesidad de introducir ningún dato más de una vez. Como se verá más adelante, la norma funStep se ha utilizado en el desarrollo de la ontología del mueble y afines, pues constituyó el primer paso para lograr la interoperabilidad entre los SI de las empresas de este sector.

Como ejemplo de aplicación de este estándar se presenta la herramienta de definición de catálogos: Cadef (CAtalog DEFinition). Mediante esta herramienta se generan los catálogos electrónicos de muebles, que se pueden representar en ficheros XML. En el diseño de la ontología se tendrá en cuenta el modelo de datos de esta aplicación ya que en un futuro se pretende enlazarla con la ontología para transcribir los ficheros XML a RDF y obtener un modelo semántico. Los ficheros obtenidos en OWL contendrán las instancias de muebles.


- 13 -

2.2.2.1. La herramienta Cadef Cadef (CAtalog DEFinition) es una herramienta de software para el proceso de generación de catálogo de las empresas relacionadas con la industria del mueble. Como herramienta de configuración, permite la definición y la gestión de especificaciones de los productos. Dado que esta herramienta está construida bajo el estándar funStep, soporta varias funcionalidades adicionales interesantes para el fabricante: vínculos multimedia, enlaces a dibujos CAD2D y 3D, el desglose de productos, restricciones, precios según configuración, definición de las partes constituyentes de un mueble, materiales, telas, herrajes,… Al ser una herramienta nativa de implementación del estándar funStep, genera un fichero XML siguiendo las especificaciones de ISO. En la figura 2.2 se muestra una captura de pantalla del Cadef. Y en la figura 2.3 se muestra su implantación actual, enlazándola con la ontología funStep que se ha creado en el presente proyecto.

Figura 2.2 Captura de pantalla de la herramienta Cadef


- 14 -

Figura 2.3 Captura del Cadef enlazando productos a la ontología


- 15 -

2.3 La Web Semántica

2.3.1. Introducción a la Web de tercera generación

El mundo de la WWW ha permitido en la última década disponer de un volumen de información que hasta el momento era impensable por vías tradicionales. Esto, al mismo tiempo que ha propiciado el éxito de la Web, también ha originado sus principales problemas: sobrecarga de información y heterogeneidad de fuentes de información, lo cual resulta en un grave problema de interoperabilidad. La Web actual no incluye mecanismos para la interoperabilidad completa de los sistemas de información (SI) basados en la Web. Dicho de otra manera: no facilita la creación de una comprensión común y compartida de un dominio, de forma que ésta pueda ser usada por personas, organizaciones y máquinas. Esta falta de interoperabilidad produce grandes problemas en el comercio electrónico B2B como se ha comentado en apartados anteriores. El problema de la sobrecarga de información provoca dificultad para acceder a la información de la Web. Para ilustrar el problema, el ejemplo de los buscadores actuales es muy indicativo. Los motores de búsqueda de la Web actual se dedican a encontrar ocurrencias de las palabras, que les hemos indicado anteriormente, en la ingente cantidad de datos que fueron capaces de almacenar sus robots. Las ocurrencias se basan en la exactitud de las palabras que elegimos para buscar. Esto obliga a una cierta pericia en la elección de la palabra precisa para encontrar el documento correcto. Y como bien sabemos los usuarios habituales de buscadores, eso provoca que a veces sea necesario consultar docenas o cientos de páginas hasta encontrar la información deseada. Hasta el momento la intervención humana resulta imprescindible para seleccionar la información que uno desea. Si las páginas web se escribieran en un lenguaje que permitiera almacenar semántica, los buscadores web encontrarían no solo las páginas donde aparecieran las palabras de la búsqueda, sino también todas aquellas páginas donde hubiera sinónimos de esas palabras. No son los buscadores web los responsables finales de la dificultad para encontrar información en la Web, sino el lenguaje utilizado para construir las páginas web: HTML. Este lenguaje de etiquetado sólo permite especificar cómo se va a mostrar una página HTML, pero resulta inútil para dar “contexto” a una página. HTML no proporciona semántica a los datos. Los problemas comentados anteriormente ocasionan que el usuario nunca tenga la garantía de que ha encontrado toda la información relevante para su consulta. No debemos olvidar que los usuarios no pueden acceder a la información almacenada en imágenes, vídeos o archivos de sonido. En todo caso, pueden acceder a las descripciones textuales de esos archivos, si tienen. En caso contrario, el buscador jamás lo encontrará. La Web semántica propone superar las limitaciones anteriormente citadas de la Web actual, permitiendo a los usuarios delegar tareas en el software. Tiene como visión


- 16 -

la búsqueda de una Web más inteligente, en la que se pueda conseguir una comunicación efectiva entre ordenadores, y centra sus esfuerzos principalmente en la búsqueda de descripciones enriquecidas semánticamente para los datos en la Web. En este sentido, se promueven descripciones que incluyan, no solo las estructuras de datos, sino también las relaciones existentes con otros conceptos, las restricciones, reglas que permitan realizar inferencia, etc. Asimismo, se promueve la definición y reutilización de vocabularios y ontologías de conceptos que faciliten el procesamiento por parte de las máquinas (Berners-Lee, 2001). Éstas podrán, al igual que las personas, encontrar, leer, comprender (en el sentido de formular inferencias) y usar los datos de la WWW; lo cual permitirá la mejora del comercio electrónico y la búsqueda de información de manera eficaz y precisa. 2.3.2. Descripción de la Web Semántica La Web semántica es “una extensión de la Web actual en la que se proporciona la información con un significado bien definido, mejorando la forma en que los ordenadores y las personas trabajan en cooperación” (Berners-Lee, 2001). La definición formal de la Web semántica dada por el W3C se resume en las siguientes líneas:

El propósito de la iniciativa de la Web semántica es tan amplio como el de la Web: crear un medio universal para el intercambio de datos. Se considera para interconectar eficazmente la gestión de la información personal, la integración de las aplicaciones empresariales y compartir globalmente datos comerciales, científicos y culturales. Los servicios para poner datos comprensibles por las máquinas se están convirtiendo rápidamente en una propiedad para muchas organizaciones, individuos y comunidades.

La Web sólo puede alcanzar todo su potencial si llega a ser un sitio donde se puedan compartir datos y sean procesados por herramientas automáticas, así como por personas. Para adaptarse a la Web, los programas del mañana deben ser capaces de compartir y procesar datos incluso cuando estos programas se hayan diseñado de forma completamente independiente. La Web semántica es una iniciativa del consorcio World Wide Web (W3C), diseñada para desempeñar un papel de liderazgo en la definición de la Web. Éste desarrolla especificaciones abiertas para aquellas tecnologías que están preparadas para distribuciones a gran escala, e identifica -mediante el desarrollo avanzado de código abierto- los componentes de la infraestructura que en el futuro se necesitarán adaptar a la Web. En la figura 2.4 se muestra el mapa conceptual de la Web semántica, orientado a la comprensión, de forma general, de los componentes y tecnologías que integran el modelo de la Web semántica, desarrollado por el Institute for Human and Machine Cognition (IHMC) de Florida.


- 17 -

Figura 2.4 Mapa conceptual de la Web semántica (Rodríguez, 2005) La Web semántica se basará en que las máquinas comprendan el significado de la información disponible en ella; de ahí el adjetivo “semántica”. En el caso de los humanos, comprender un signo o una palabra no es nada extraordinario, nuestro cerebro lo asocia a los conceptos que ha ido almacenando a lo largo de los años, digamos que la interpretación semántica la proporcionan nuestras estructuras neuronales. Pero para las máquinas actuales, “comprender” no debe entenderse en el sentido de “comprensión humana”, sino en el sentido de “inferir, deducir”. Que las máquinas entiendan o comprendan los datos significa que, mediante procesos lógico-matemáticos, sean capaces de inferir conclusiones a partir de los datos. Hoy en día, existen ya - según diversos autores - las tecnologías que llevarán a la Web semántica. Tim Berners-Lee (Berners-Lee, 1998) ideó una infraestructura de lenguajes y mecanismos, dividida en varias capas o niveles, para poder llevar a cabo la idea de la Web Semántica. El diagrama de la figura 2.5, presentado por Berners-Lee en la XML Conference del año 2000, puede servir como aproximación visual al conjunto de tecnologías que forman el esquema de capas mencionado, cuyos componentes son:

Estándares para la localización de recursos de información en el web de forma inequívoca y única como son los URIs (Uniform Resource Identifiers) y la norma internacional Unicode para la codificación de caracteres a nivel internacional.


- 18 -

XML (eXtensible Markup Language ), como base sintáctica para la estructuración del contenido en el web, así como el empleo de espacios de nombres (Namespaces) para asociar con precisión cada propiedad con el esquema que define dicha propiedad y esquemas (XML Schema ) para definir qué elementos debe contener un documento XML, cómo están organizados, qué atributos y de qué tipo pueden tener sus elementos.

Un modelo básico para establecer propiedades sobre los recursos, para el que se empleará RDF (Resource Description Framework), así como un modelo para definir relaciones entre los recursos por medio de clases y objetos, que se expresan mediante esquemas en RDF (RDF Schema).

Lenguajes para la representación de ontologías que permitan la interoperabilidad y reutilización entre ontologías de diversos dominios del conocimiento en el web, cuya base se encuentra en RDF Schema .

Una capa lógica que permita realizar consultas e inferir conocimiento; donde estarían las ontologías, agentes de software y servicios web como estructuras para lograr interoperabilidad entre aplicaciones y sistemas de información heterogéneos.

Una capa de seguridad que permita asignar niveles de fiabilidad a determinados recursos, de forma comprobable posteriormente por los agentes, para lo que se utilizarán firmas digitales y redes de confianza.

Figura 2.5 Esquema de la web semántica

La unión de todas estas capas produciría una Web Semántica potente, segura y amigable. En los próximos apartados hablaremos más sobre estas tecnologías. Con ellas, la Web pasará de ser una colección de documentos a ser una base de conocimiento, de la cual se podrán extraer conclusiones a partir de premisas.


- 19 -

2.3.3. Representación del conocimiento El concepto de documentos que las máquinas puedan entender no implica ninguna inteligencia artificial que permita a la máquina comprender los murmullos humanos. Sólo indica la habilidad de la máquina para resolver un problema bien definido desarrollando operaciones bien definidas sobre datos bien definidos. En lugar de pedir a las máquinas que entiendan el lenguaje humano, implica pedir a la gente que haga un esfuerzo (Berners-Lee, 1998). La expresión “pedir a la gente que haga un esfuerzo” significa que los humanos deben representar los datos en algún lenguaje formal (lógico y axiomático), de manera que las máquinas puedan usarlos para extraer inferencias lógicas. Estos lenguajes, vinculados a la representación del conocimiento, se conocen como lenguajes de representación de conocimiento. Se han utilizado diversos formalismos para representar el conocimiento en los sistemas de información. En bases de datos se han utilizado diagramas entidad-relación para definir los conceptos y sus relaciones en un determinado universo. En programación se han utilizado gramáticas y estructuras de datos como clases y objetos. En Ingeniería del Software se ha propuesto el uso de lenguajes de modelado como UML, donde también se pueden definir clases y sus relaciones. En Inteligencia Artificial, algunas de las formas que se han utilizado para representar el conocimiento son la lógica matemática y las estructuras de datos. En la lógica matemática destacan los enfoques basados en lógica y los basados en reglas. Los sistemas basados en lógica utilizan fórmulas lógicas para representar relaciones complejas. Dentro éstos, las que tienen el poder expresivo más alto son las lógicas de orden mayor, sin embargo, este mecanismo tiene varias desventajas entre las que se encuentra su ineficiencia para manejo de grandes combinaciones de conceptos. Se entiende por lógica de mayor orden un lenguaje en el que las variables pueden aparecer en cualquier parte donde los predicados y/o funciones lo hagan. Si no se requiere una semántica de orden mayor, ésta puede ser simplificada en lógica de primer orden (LOP) (Samper, 2005). La Lógica de Predicados permite establecer formalmente sentencias (predicados) sobre cosas y colecciones de cosas, sus tipos y propiedades, así como clasificarlas y describirlas. Es un ejemplo donde la sintaxis y la semántica son ambas de primer orden. Finalmente, realizar razonamiento sobre la LOP es computacionalmente intratable para grandes cantidades de datos. Ciertos subconjuntos de la LOP, especializados en clasificar cosas, se denominan lógicas descriptivas (cada familia de lógicas descriptivas se origina de un determinado subconjunto de la LOP). Es cierto que las lógicas descriptivas carecen de la potencia expresiva de la LOP, sin embargo son matemáticamente trazables y son computables. Por otra parte los sistemas basados en reglas permiten representar el conocimiento en formas de cláusulas IF-THEN u otras condiciones de acción. Estas


- 20 -

reglas son usadas posteriormente por los motores de razonamiento para inferir conocimiento a partir de las reglas definidas inicialmente. En relación con los sistemas de representación del conocimiento basados en estructuras de datos, se destacan los siguientes:

Redes semánticas: Consisten en un conjunto de nodos que representan objetos, conceptos o situaciones y enlaces que representan las relaciones entre los nodos.

Marcos (frames): Representan conceptos denominados clases y relaciones llamados slots. Los esquemas de representación basados en marcos insisten en una organización jerárquica, mientras que las redes semánticas no requieren de tal organización

Redes de herencia estructurales: Desarrolladas para subsanar las

ambigüedades de las dos anteriores, y su puesta en práctica se realizó en el sistema KL-ONE (Brachman, 1985, citado por Samper, 2005; Brachman, 1978, citado por Samper, 2005).

Sistemas terminológicos o Descripciones Lógicas: Son un tipo de lenguaje de representación basado en lógica que ha sido diseñado para razonar sobre redes semánticas y frames.

Grafos, Redes de Petri, Mapas Tópicos: Son estructuras de representación de más bajo nivel que constituyen la base formal de otros mecanismos recientes de representación del conocimiento. John F. Sowa afirma que “la representación de conocimiento es un área

multidisciplinar que aplica teorías y técnicas de los campos de la Lógica, Ontologías y la Computación”. Para este autor, la lógica provee la estructura formal y las reglas de inferencia, y sin ella no existirán criterios para determinar si hay sentencias contradictorias o redundantes. Las ontologías permiten que los términos y símbolos que existen en el dominio de aplicación estén bien definidos y no den lugar a confusión. Por último, los modelos de computación permitirán implementar las dos primeras disciplinas en programas de aplicación (Sowa, 2000, citado por Samper, 2005).

Resumiendo lo anterior, se puede concluir que la lógica es relevante para la Web semántica por tres motivos:

1) Permite desarrollar lenguajes formales que permiten representar el conocimiento.

2) Proporciona semánticas bien definidas: en un sistema lógico, cada símbolo y cada expresión tienen un significado único e inambiguo.

3) Proporciona reglas de inferencia, a partir de las cuales se pueden extraer

consecuencias del conocimiento (estas reglas permiten validar demostraciones, es decir, comprobar si una consecuencia se deriva de unas premisas). Lo que se conoce como interpretación semántica automática de documentos no pasa de ser la aplicación de reglas lógicas a unos datos


- 21 -

presentados en algún lenguaje formal (como OWL, DAML, DAML+OIL o KIF/CL). Estos lenguajes se basan en la lógica descriptiva (lógica que proporciona un formalismo para expresar el conocimiento humano, basándose en métodos de razonamiento bien establecidos y procedentes de un subconjunto de la lógica de predicados o de primer orden).

2.3.4. XML: primer paso hacia la Web semántica

XML (eXtensible Markup Language) fue desarrollado por el grupo de trabajo XML del W3C, que estableció la segunda edición de la versión 1.1 como recomendación el 16 de agosto del 2006 (XML, 2006). Se desarrolló para proporcionar una flexibilidad y eficiencia que no se podían alcanzar con HTML. Mientras que HTML es un lenguaje de marcado para documentos de hipertexto, XML es un lenguaje de marcado de documentos de todas clases. Se dice que es extensible porque permite al programador asociar sus propias etiquetas (metadatos) a los datos.

Desde la aparición de XML en 1998, se han definido multitud de estándares para

modelizar información en dominios específicos como las finanzas (XBRL, RIXML, etc.), el periodismo (p.e. News ML, PRISM), la enseñanza (SCORM, IEEE LOM y otros), o la medicina (NLM Medline, SCIPHOX, CDA, etc.), entre otros muchos campos (Castells, 2003).

Figura 2.6 Ejemplo de documento XML

XML constituye un gran paso adelante para lograr la interoperabilidad sintáctica,

que es necesaria para el comercio electrónico. Actualmente XML es el lenguaje en el que se está apoyando el e_business para mejorar sus servicios, y que en un futuro cercano será utilizado por todos en la Web. He aquí algunas de las ventajas generales de usar XML:

Es capaz de expresar cualquier documento y cualquier tipo de dato. Permite

definir los datos independientemente de cualquier lenguaje o plataforma y, por ello, constituye un formato universal para el intercambio de datos.

Es autodescriptivo. Además de almacenar los datos, almacena la estructura de éstos. Resulta fácil compartir documentos XML entre empresas y personas, ya que una persona que lea un documento XML es capaz de descubrir enseguida su estructura.


- 22 -

Es flexible: los documentos XML pueden desarrollarse tal y como se quiera.

Nada impide a una empresa que desarrolle una serie de esquemas, XML Schema o DTDs (Document type definition) para los tipos de documentos con que trabaja (facturas, pedidos, órdenes de producción, albaranes, reclamaciones...) y que exija a sus clientes y proveedores que usen documentos XML conformes a esos esquemas o DTDs.

La comprobación de la estructura de los documentos se puede hacer de forma

automática, de modo que se rechacen aquellos documentos que no estén construidos siguiendo los esquemas o DTDs elegidos. Con lo que se evita el envío de documentos incorrectos.

Al basarse en texto ordinario, los documentos XML son idóneos para transportarlos a través de Internet; red donde conviven muchas plataformas y sistemas informáticos distintos, cada uno con sus propios formatos de archivos.

Se pueden crear documentos XML para casi todos los lenguajes humanos, ya que el juego de caracteres predefinido para él es el Unicode.

Figura 2.7 Ejemplo de DTD del XML de la figura anterior

XML es un primer paso en la dirección de avanzar hacia una representación explícita de los datos y la estructura de los contenidos de la web, separada de su presentación en HTML. XML proporciona una sintaxis para hacerlo posible, pero ofrece una capacidad limitada para expresar la semántica. El modelo de datos XML consiste en un árbol que no distingue entre objetos y relaciones, ni tiene noción de jerarquía de clases.

Por lo tanto, a pesar de todas las excelencias de XML, no proporciona una interoperabilidad completa, pues no incorpora ningún mecanismo para garantizar la interoperabilidad semántica. XML sirve para especificar el formato y estructura de cualquier documento; pero no impone ninguna interpretación común de los datos del documento. El marcado de los documentos XML es una forma de metadatos. Etiquetas como <precio> o <autor> ayudan a que los humanos intuyamos el significado de lo que vaya entre las etiquetas, pero para un programa que procese documentos XML, las etiquetas carecen de significado.


- 23 -

En el caso del comercio B2B, que XML no incluya ningún mecanismo para la interpretación semántica constituye un gran problema. Varias empresas pueden intercambiar documentos XML si todas las partes se han puesto de acuerdo sobre las DTD (o los esquemas) que van a usar, pero surgirán problemas cuando aparezcan empresas que usen otras DTD, aunque sean equivalentes. Por ejemplo, un SI que acepte etiquetas <precio> no será capaz de procesar etiquetas <precioUnidad>, aunque sean semánticamente equivalentes. Sin embargo, XML es el pilar en el que sustentan el resto de lenguajes o tecnologías de la Web. XML supone un formato universal: “Todo debe estar escrito en XML” (Llórens, 2005). Otra de las funciones actuales que tiene es encapsular la información o partes de una ontología para que sea intercambiada a través de los diferentes protocolos de intercambio de datos XML a través de la Web (por ejemplo SOAP). La familia de las tecnologías asociadas a XML es muy extensa destacando Xpath, XPointer, XLink, XSL y CSS principalmente (Martín, 2005).

2.3.5. Ontologías El término Ontología proviene de la filosofía y es una teoría que trata de la naturaleza y organización de la realidad, es decir de lo que “existe”. Conocimiento del ser (del griego onto: ser y logos: conocimiento).

La definición de ontología más concisa es la del consorcio W3C: “La ontología es un término tomado prestado de filosofía que se refiere a la ciencia de describir los tipos de entidades en el mundo y cómo se relacionan entre ellos.” (MacGuinness y Harmelen, 2004) La definición más empleada en la literatura de Web Semántica procede de Gruber: “Una ontología es una especificación explícita y formal de una conceptualización” (Gruber, 1993). En esta definición, conceptualización significa un modelo abstracto; explícita significa que los elementos deben ser claramente definidos; y formal significa que la especificación debe ser procesable por una máquina. Yendo más lejos, desde el punto de vista de Gruber, una ontología es la representación del conocimiento de un dominio, donde un conjunto de objetos y sus relaciones son descritos por un vocabulario. Puede decirse que una ontología define un vocabulario común para los que necesitan compartir información sobre un dominio. Cabe señalar que no todas las ontologías deben ser formales: existen ontologías que se expresan de una forma restringida y estructurada del lenguaje natural, e incluso mediante el lenguaje natural (español, francés, inglés,…). En lo que sigue se considerará sólo las ontologías formales, que tienen semánticas que describen el significado de una forma precisa. Es decir, que la semántica no se refiere a opiniones ni intuiciones, y que las máquinas y las personas deben interpretarla de una misma forma. En definitiva, una semántica formal usa la lógica de


- 24 -

primer orden o un subconjunto de ella (como las lógicas descriptivas). Es indispensable disponer de una semántica formal para implementar sistemas de inferencia o de razonamiento automático (sin intervención humana). Son varias las utilidades del razonamiento automático:

Se puede comprobar automáticamente si una ontología es consistente con el conocimiento del dominio de interés que representa.

Se puede comprobar automáticamente si las relaciones entre las clases corresponden a los propósitos de la ontología y se pueden detectar relaciones espurias.

Permite clasificar automáticamente las instancias en clases.

Las ontologías son una herramienta para compartir información y conocimiento, es decir, para conseguir la interoperabilidad. Al definir un vocabulario formal de los conceptos del dominio y un conjunto de relaciones entre ellos, permite que las aplicaciones “comprendan” la información.

Por lo general, el aspecto que toman consiste en una forma jerárquica de términos que representan los conceptos básicos de un determinado dominio.

Figura 2.8 Las ontologías establecen redes semánticas Las ontologías han sido utilizadas en diferentes áreas de las ciencias de la computación, tales como inteligencia artificial, representación del conocimiento, procesamiento del lenguaje natural, Web Semántica e ingeniería del software, entre


- 25 -

otras. Por lo tanto, es razonable que haya una cierta divergencia entre sus múltiples definiciones. A pesar de que una ontología pueda tomar una gran variedad de formas, necesariamente incluirá un vocabulario de términos, alguna especificación de su significado y una indicación de cómo los conceptos se interrelacionan, lo cual impone una estructura sobre el dominio y restringe las posibles interpretaciones de los términos (Uschold, 1999). Las ontologías tienen los siguientes componentes que servirán para representar el conocimiento de algún dominio (Gruber, 1993b, citado por Samper):

Conceptos: son las ideas básicas que se intentan formalizar. Pueden ser clases de objetos, métodos, planes, estrategias, procesos de razonamiento, etc.

Relaciones: representan las interacciones y enlaces entre los conceptos del dominio. Suelen formar la taxonomía del dominio.

Funciones: son un tipo concreto de relación donde se identifica un elemento

mediante el cálculo de una función que considera varios elementos de la ontología.

Instancias: se utilizan para representar objetos determinados de un concepto.

Axiomas o reglas: son teoremas que se declaran sobre relaciones que deben

cumplir los elementos de la ontología. Permiten junto al mecanismo de la herencia de conceptos, inferir conocimiento que no esté indicado explícitamente en la taxonomía de conceptos.

En el mundo de las ontologías no existen verdades absolutas, ya que éstas son entidades construidas artificialmente que se crean, no se descubren, y especifican una forma de ver el mundo, por tanto un punto de vista. Por este motivo existen varias técnicas (provenientes de la IA o de la ingeniería del software o de bases de datos) que permiten modelar una ontología. Ahora bien, hay que destacar que el modelo sólo se podrá considerar una ontología si contiene un modelo de conocimiento consensuado y compartido por la comunidad de interés. En breve, un acuerdo con respecto a una ontología común es una garantía de consistencia, pero no de completitud, con respecto a las búsquedas y aserciones, usando el vocabulario definido en la ontología. (Viegas et al., 1999) Independientemente de la definición adoptada, es importante entender que las ontologías son empleadas para describir una gran variedad de datos y modelos. Normalmente, las ontologías – en el sentido dado por Gruber – parten de taxonomías previas. Más adelante se explican las diferencias entre éstas y aquéllas. 2.3.5.1 Elementos de una ontología Antes de continuar con la sección de ontologías, se definirán algunos conceptos para facilitar al lector la comprensión de los siguientes apartados.


- 26 -

Clases: representan los conceptos que forman el ámbito de la ontología. Los conceptos son las ideas básicas que se intentan formalizar y son el elemento principal de una ontología. Por ejemplo, en una ontología que representase la estructura política de España, "PartidoPolítico" y "ComunidadAutónoma" podrían ser clases de la ontología.

Subclases. Cuando una clase A es la generalización de otra clase B, se dice que

B es subclase (hija) de A. Siguiendo el ejemplo de antes, “PartidoSocial” sería subclase de “PartidoPolítico”. Responde afirmativamente a la pregunta “¿Un partido social es un partido político?”

Clases Hermanas. Dos clases son hermanas si comparten la clase padre. Son

subclases de una misma clase. Las clases “PartidoSocial”y “PartidoPopular” serían hermanas.

Clases disjuntas: son clases diferentes, un elemento de una no puede ser

también elemento de la otra.

Propiedades: establecen relaciones entre conceptos de la ontología. Por ejemplo, la propiedad “esMiebroDePartido” relaciona una persona con el partido al que pertenece. En una propiedad hay que definir el rango y el dominio.

Rango: define el Objeto que es afectado por la propiedad.

Dominio: define el Sujeto que será definido por la propiedad. Digamos, el

conjunto de valores que podrá tomar esa propiedad.

Instancias: son entidades que pertenecen a una determinada clase. Por ejemplo, "Andalucía" es una instancia de la clase "ComunidadAutónoma" y "PSOE" es una instancia de la clase "PartidoPolítico". Las clases se suelen organizar en una jerarquía, donde las instancias de una subclase pertenecen a la clase. Por ejemplo, podríamos tener en nuestra ontología la clase "localización" de la que sería subclase "ComunidadAutónoma".

2.3.5.2 Tipos de Ontologías Las ontologías se pueden clasificar teniendo en cuenta diferentes criterios. En la literatura pueden encontrarse muchas posibilidades. Veamos dos de ellas:

1. Según el alcance de su aplicabilidad:

Ontologías de Dominio. Proporcionan el vocabulario necesario para describir un dominio dado o subdominio, como la medicina, el tráfico, el sector mobiliario. Incluyen términos relacionados con: Los objetos del dominio y sus componentes. Un conjunto de verbos o frases que dan nombre a actividades y

procesos que tienen lugar en ese dominio.


- 27 -

Conceptos primitivos que aparecen en teorías, relaciones y fórmulas que regulan o rigen el dominio.

Ontologías Generales: Representan conceptos generales que no son

específicos de un dominio. Por ejemplo, ontologías sobre el tiempo, el espacio, ontologías de conducta, de causalidad, etc.

Ontologías de Tareas. Proporcionan el vocabulario para describir términos involucrados en los procesos de resolución de problemas los cuales pueden estar relacionados con tareas similares en el mismo dominio o en dominios distintos. Incluyen nombres, verbos, frases y adjetivos relacionados con la tarea (“objetivo”, “planificación”, “asignar”, “clasificar”,…).

2. Según la granularidad de la conceptualización (cantidad y tipo de

conceptualización):

Terminológicas: Especifican los términos que son usados para representar conocimiento en el universo de discurso. Suelen usarse para unificar vocabulario en un dominio determinado (contenido léxico y no semántico).

De información: Especifican la estructura de almacenamiento de bases de datos. Ofrecen un marco para el almacenamiento estandarizado de información (estructura de los registros de una BD).

De modelado del conocimiento: Especifican conceptualizaciones del

conocimiento. Poseen una rica estructura interna y suelen estar ajustadas al uso particular del conocimiento que describen (términos y semántica).

2.3.5.3 Ontologías frente a Taxonomías Una taxonomía es una clasificación estricta de términos de forma jerárquica, usando la relación padre-hijo (generalización, “es-un”, o tipo-de). Las taxonomías no permiten definir atributos para los términos. Un ejemplo de taxonomía es la estructura de directorio de nuestro ordenador. Es una jerarquía severa y estricta que sólo establece relación entre los nombres de los directorios (vocabulario) y la estructura jerárquica. Una ontología es una taxonomía ampliada, donde además de un vocabulario que nos define el contenido de una estructura, podemos establecer información documental a la propia jerarquía, establecer reglas, restricciones lógicas y definir axiomas que nos hagan llegar a una meta como el razonamiento automático o inferencia. Según Noy y MacGuinness (Noy y MacGuiness, 2001) hay tres propiedades que una ontología debe poseer para diferenciarla de una taxonomía o tesauro:

Estricta jerarquía de conceptos: toda instancia de una clase debe ser también


- 28 -

instancia de su clase padre. La organización de términos debe seguir una relación de generalización.

Interpretación no ambigua de significados y relaciones: los usuarios deben definir propiedades, cuyos valores deben ser restringidos a ciertos dominios.

El uso de un vocabulario controlado y finito, pero extensible.

2.3.5.4 Lenguajes de ontologías Existen multitud de lenguajes que permiten la representación de ontologías: OIL (Ontology Inference Layer), DAML (DARPA Agent Mark-Up Language), SHOE (Simple HTML Ontology Extensión), TopicMaps, OCLM, Ontolingua, LOOM, CycL, etc. No todos ellos permiten el mismo nivel de expresividad a la ontología construida ni tampoco ofrecen las mismas funcionalidades. A la hora de elegir un lenguaje para la definición de una ontología deben tenerse en cuenta los siguientes aspectos:

El lenguaje debe poseer una sintaxis bien definida para poder “leer” con facilidad la ontología definida.

Debe tener una semántica bien definida para comprender perfectamente el funcionamiento de la ontología.

Debe tener suficiente expresividad para poder capturar varias ontologías. Debe ser fácilmente mapeable desde/hacia otros lenguajes ontológicos. Debe ser eficiente a la hora de realizar razonamiento.

Merece la pena destacar dos lenguajes intermedios, KIF y PIF, que son los que usan aplicaciones heterogéneas e independientes cuando necesitan intercambiar conocimiento.

KIF (Knowledge Interchange Format): Desarrollado por el grupo de trabajo Interlingua de la universidad de Standford en 1992 con el propósito de resolver el problema de la heterogeneidad en los lenguajes de representación del conocimiento. Se trata de un lenguaje formal con notación tipo Lisp para escribir los axiomas en las definiciones de Ontolingua.

PIF (Process Interchange Format): Tiene el mismo propósito que el anterior, es

decir, facilitar compartir el conocimiento entre diferentes procesos de software. En su desarrollo, de 1993 a 1996, participaron grupos del MIT, de Stanford, de Toronto, etc. Permite el intercambio de descripciones de procesos del mundo de los negocios dentro de una organización y entre varias organizaciones.


- 29 -

2.3.5.4.1 Lenguajes tradicionales Los lenguajes de ontologías tradicionales se distinguen según la forma en la que se basan para representar el conocimiento: basado en frames, en lógica descriptiva, predicados de primer orden y segundo orden, o los orientados a objetos. A continuación se exponen los más representativos (Gómez-Pérez, 2004):

Ontolingua (Ontolingua, 2004) fue desarrollado en 1992 por KSL (Universidad de Standford), es un lenguaje de ontologías basado en KIF y en Frame Ontology (FO) empleado en el Ontolingua Server. KIF permite definir objetos, relaciones y funciones y utiliza predicados de lógica de primer orden. Como KIF es un lenguaje no orientado a construir ontologías, sino para intercambio de conocimiento, Ontolingua emplea FO para permitir la descripción de ontologías utilizando los paradigmas de frames, y con el que empezaron a surgir términos como clase, instancia o subclase. FO no permitía axiomas, pero al surgir a partir de KIF, sí permite que se incluyan axiomas de KIF dentro de sus definiciones.

OKBC Protocol (Open Knowledge Base Connectivity Protocol), como su

nombre indica no se trata de un lenguaje sino un protocolo basado en el GFP (Generic Frame Protocol), es decir, basado en frames. Es utilizado como complemento de lenguajes de representación de conocimiento, y permite, como otros sistemas basados en frames, clases, constantes, atributos, frames e instancias que sirven de base de conocimiento. También implementa una interfaz para acceder al conocimiento al igual que funciones utilizadas para acceder a través de la red a un conocimiento compartido. Fue empleado junto a Ontolingua (OKBC, 1995).

OCML (Operational Conceptual Modeling Language) fue desarrollado

originalmente como parte del proyecto VITAL (Shadbolt, 1993, citado por Samper, 2005). Es un lenguaje basado en marcos que aporta mecanismos para expresar ítems tales como relaciones, funciones, reglas, clases e instancias. Se le añadió un módulo de mecanismos de lógica y una interfaz para poder interactuar con el conocimiento. Una de las ventajas que tiene es que es compatible con estándares como Ontolingua (OCML, 1999).

Flogic (Frame Logic) fue desarrollado en 1995 en la Universidad de

Karsruhe. Integra marcos y calcula predicados de primer orden. Permite la representación de conceptos, taxonomías, relaciones binarias, funciones, instancias, axiomas y reglas deductivas. Tiene una estructura con aspectos parecidos a la los lenguajes orientados a objetos, como la herencia, tipos polimórficos, etc. Con Flogic se han creado de bases de datos hasta ontologías y se puede combinar con otros programas de lógica para interactuar con la información almacenada en la ontología (Flogic, 2004).


- 30 -

2.3.5.4.2 Lenguajes basados en estándares y en Web Estos lenguajes fueron desarrollados específicamente para el desarrollo de ontologías. Se basan en los lenguajes de marcado HTML y XML. Se diferencian de los anteriores porque fueron desarrollados orientados para ser utilizados en la web. Dado que la web es mucho más extensa que una base de conocimiento, es necesario el uso de estándares que permitan implementar ontologías en este ambiente. Los más destacados son: el lenguaje RDF (Resource Description Framework) que implementa un modelo básico para establecer propiedades sobre los recursos, y el lenguaje OWL que tiene como punto de partida experiencias previas realizadas en el lenguaje DAML-OIL y que se divide en tres sublenguajes de diferente expresividad semántica: OWL-Lite, OWL-DL y OWL-Full. Todos estos lenguajes se sustentan para su formalización en el XML, metalenguaje que permite definir y validar los lenguajes de etiquetado que se usan en la Web. Se va a ver la definición y las características de los más destacados:

RDF y RDFS RDF (Resource Description Framework, Marco de Descripción de Recursos)

(RDF, 2004a; RDF, 2004b) fue desarrollado por el World Wide Web Consortium (W3C) con el objetivo de “especificar semántica, para los datos basados en XML, de una manera interoperable y estandarizada. Su recomendación por la W3C fue establecida el 10 de febrero de 2004, establece la sintaxis y estructura que permite la descripción de metadatos y permite que el significado sea asociado con los datos a través de RDF Schema (RDFS, 2004), el cual facilita la definición de ontologías específicas de dominio. Se trata de una infraestructura que permite la interoperabilidad de metadatos mediante el diseño de mecanismos que dan soporte a las convenciones comunes de semántica, sintaxis y estructura. RDF hace uso de XML como sintaxis común para el intercambio y proceso de metadatos, proveyendo independencia, extensibilidad, validación, legibilidad humana, y la habilidad para representar estructuras complejas. RDF explota estas características imponiendo a su vez, estructuras que permiten expresividad semántica inequívoca. Provee además un medio para publicar vocabularios

legibles por los humanos y capaces de ser procesados por las máquinas, y éstos pueden ser reutilizados, extendidos o refinados para adaptarlos a los diferentes dominios específicos según sus requerimientos. Aunque suela decirse que RDF es un lenguaje, resulta más exacto describirlo como un modelo de datos para las instancias de metadatos o, por abreviar, como un modelo de metadatos. RDF basa su modelo en tres partes:

Recursos (sujeto) que son todo aquello de lo que se puede decir algo y son referenciados por un identificador único de recursos (URI).

Propiedades (predicados) que definen atributos, aspectos, características o representan una relación que describe a un recurso.


- 31 -

Declaraciones (objeto) los cuales nos sirven para dar valores a las propiedades de un recurso específico. El objeto de un estamento puede ser un recurso o un literal, por ejemplo, un recurso especificado por un URI, o bien un string u otras primitivas de datos definidas por XML.

Los tres constituyen una tripleta (sujeto, predicado, objeto) que es la

construcción básica en RDF. Un conjunto de dichas tripletas es llamado grafo RDF, el cual define la sintaxis abstracta de RDF. Esto puede ilustrarse a través de un diagrama de nodos y arcos dirigidos (ver figura 2.9), en el cual cada tripleta es representada como un enlace nodo-arco-nodo (de allí el término grafo).

Figura 2.9 Diagrama de nodos y arcos. En la figura 2.10 se incluye la representación gráfica de tripletas de RDF.

Figura 2.10 Representación de tripletas RDF. Nótese que las propiedades (dirección, ciudad, código postal, calle y estado) y el

sujeto se representan como URIs, mientras que los objetos se representan como cadenas de texto. Nada impide que los objetos se representen mediante URIs: un URI puede ser construido para cualquier entidad o recurso (tangible o intangible) que pueda ser nombrado, por lo que los hechos RDF pueden referirse, consecuentemente, a cualquier cosa (Rodríguez, 2005).


- 32 -

RDF se puede emplear en cualquier campo: no se asocia a ningún dominio en particular. Cada organización o persona puede definir su propio vocabulario mediante lo que se conoce como RDF Schema (esquema de RDF), que se define en función de las sentencias RDF (Abián, 2005).

RDF Schema permite la definición de jerarquías de clases (relación de subclase y subpropiedad) de objetos y propiedades (relaciones binarias) y permite la creación de restricciones (rango y dominio). Este esquema se aproxima más al concepto de ontología ya que se dispone de relaciones diseñadas para especificar la jerarquía de la taxonomía de conceptos que define un conocimiento.

RDF(S) funciona como un modelo semántico de datos capaz de permitir preguntas referentes a su contenido y no a la estructura del documento. RDF Schema incluye tres clases principales (Abián, 2005):

1) rdfs:Resource. Se consideran instancias de esta clase los recursos, que son todas las entidades descritas por expresiones RDF.

2) rdfs:Class. Las clases RDF pueden representar páginas web, organizaciones, personas, búsquedas en la Web, etc. Toda clase es miembro de rdfs:Class. Cuando se crea una nueva clase mediante un esquema RDF, la propiedad rdf:type del recurso representado por la clase adquiere como valor el recurso rdfs:Class o alguna subclase suya. Cuando un recurso tiene la propiedad rdf:type cuyo valor es una clase determinada, se dice que el recurso es una instancia de esa clase.

3) rdf:Property. Representa el subconjunto de recursos RDF que son propiedades.

El dominio y rango de estos recursos se describen mediante las propiedades rdfs:domain y rdfs:range respectivamente; las jerarquías de propiedades se describen mediante rdfs:subPropertyOf. Tanto rdfs:range como rdfs:domain son instancias de rdf:Property. El rango se usa para establecer que los valores de una propiedad son instancias de una o más clases. Y el dominio se emplea para establecer que un recurso con una cierta propiedad es instancia de una o más clases. Una propiedad relevante de RDF Schema es rdfs:subClassOf, que describe una

clase como subclase de otra. Solamente las instancias de rdfs:Class pueden tener dicha propiedad.

Para los metadatos, RDF Schema define varias propiedades:

rdfs:comment proporciona la descripción en lengua natural de un recurso. Por ejemplo, <rdfs:comment> “Las neveras enfrían lo que se introduce en ellas” </rdfs:comment>.

rdfs:label proporciona una versión legible para los humanos del nombre del recurso. P.e.,<rdfs:label>Frigorífico</rdfs:label>.

rdfs:seeAlso especifica un recurso que proporciona información


- 33 -

adicional sobre el recurso principal. P.e., <rdfs:seeAlso> http://www.vocabulario.es/aparatos </rdfs:seeAlso>

rdfs:isDefinedBy indica cuál es el recurso donde se define el recurso

principal. Es una subpropiedad de rdfs:seeAlso. La Web semántica no sería posible solo con RDF y XML debido a que RDF Schema presenta muchas carencias: Cuando se define un rango para una propiedad, se define para todas las clases.

No se pueden declarar restricciones de rango que sean válidas solo para algunas clases.

No se pueden representar algunas características de las propiedades, como que una propiedad sea: transitiva, simétrica, inversa o única.

No se puede reflejar que algunas determinadas clases son disjuntas. Por ejemplo, en RDF Schema puede declararse que Hombre y Mujer son subclases de Persona, pero no que son disjuntas. Es decir, resulta imposible especificar que ninguna persona puede ser a la vez hombre y mujer.

No permite expresar restricciones de cardinalidad. Así, no se puede expresar que una cuenta bancaria no puede tener más de seis titulares, por ejemplo, o que un hijo siempre tiene un padre o una madre.

Hay algunas expresiones que no pueden expresarse mediante la lógica de primer orden. Esto causa que haya sentencias indecidibles. Sentencias de las que, dado un sistema de axiomas o premisas, no se puede afirmar ni negar nada.

En suma, RDF no es lo bastante completo para describir los recursos de la Web

con el detalle que se precisa. Se utiliza porque es tan general que puede emplearse en muchos dominios y porque actúa como puente entre los vocabularios de cada uno.

DAML+OIL El programa DAML (DARPA Agent Markup Language) es una iniciativa de DARPA (Defense Advance Research Projects Agency) en 1999 con el objetivo de proveer los fundamentos de la Web semántica. Los usuarios de RDF y RDFS conforme utilizaban estos lenguajes para expresar los metadatos de sus recursos, observaban que ambos lenguajes describían un conjunto escaso de facilidades para expresar estos metadatos. Por ejemplo, no podían hacer uso de datatypes del XMLSchema (XMLS, 2001), no podían hacer enumeraciones etc. La comunidad de usuarios vieron en RDF una herramienta para expresar sus recursos, pero también lamentaban que no existiesen facilidades para permitir la inferencia sobre las descripciones RDF. Tenía que surgir una evolución de este lenguaje que permitiese el razonamiento sobre las descripciones. Por estos motivos, unieron sus esfuerzos los desarrolladores de DAML con los de


- 34 -

OIL para favorecerse de los sistemas de clasificación basados en frames de este último. El resultado final fue el lenguaje DAML+OIL( DAML+OIL, 2001), un lenguaje que a pesar de tener muchas coincidencias con OIL, también tiene sus diferencias, la principal es que se trata de un lenguaje que se aleja de los ideales de frames de OIL, para acercarse más a una base de lenguajes de lógica descriptiva.

Por lo tanto, DAML+OIL es un lenguaje que tiene una semántica sencilla y bien definida, y que nos ofrece más expresiones sofisticadas para las descripciones de clasificaciones y propiedades de los recursos que las que ofrecía RDF y RDFS.

DAML+OIL es la evolución de RDFS, en el que se redefinen muchas de sus

descripciones y se añaden muchas otras para mejorar el lenguaje y aportar propiedades y mecanismos para que el lenguaje defina ontologías que después pueden ser empleadas por sistemas de razonamiento para poder inferir sobre la información.

Sin una semántica bien definida y procedimientos de inferencia, los Agentes no

serán capaces de procesar la información de forma consistente. Como una plataforma desde donde manejar las ontologías, DAML + OIL es bastante útil, según sus propios autores, es una alternativa firme a RDF Schema u otros. OWL

OWL (Ontology Web Language) (OWL, 2004) surge del W3C como la búsqueda de un lenguaje de especificación de ontologías que sirva como estándar para todos los investigadores de la Web semántica. Deriva del lenguaje DAML + OIL y se construye sobre la sintaxis de RDF/XML. Se le pretende dar tantas funcionalidades como las que posee DAML + OIL, aunque diferenciándose en algunas. OWL también es una extensión de RDFS y emplea el modelo de tripletas de RDF. En parte, es un RDFS mejorado, que mantiene una buena relación entre eficacia computacional y poder expresivo. Con OWL se pueden definir clases mediante restricciones a otras clases, o con operaciones booleanas sobre otras clases, hay nuevas relaciones entre clases como la inclusión, disyunción y la equivalencia, se pueden definir restricciones de cardinalidad en propiedades o dar propiedades sobre las relaciones (transitiva, simetría) así como permitir clases enumeradas. Como pude verse, OWL tiene mucha más capacidad expresiva que RDFS. Además, OWL facilita la importación y exportación de clases: incluye propiedades como sameAs, equivalentClass, equivalentProperty, differentFrom, etc. Por ejemplo, equivalentClass permite establecer que dos clases de distintas ontologías sean equivalentes (p.e. onto1:Persona y onto2:SerHumano), esto significa, que cada instancia de una clase será también instancia de la otra clase, y viceversa. La capacidad de expresar que dos clases son iguales resulta muy útil cuando se integran o mezclan ontologías y permite la interoperabilidad. Una ontología en OWL es una secuencia de axiomas, hechos y referencias a otras ontologías, que se consideran incluidas en la ontología. Las ontologías OWL son documentos web, y pueden ser referenciados a través de una URI.


- 35 -

OWL se decidió separar en tres niveles, atendiendo a su expresividad semántica:

OWL Lite: la versión más simple para los programadores principiantes. Permite la jerarquía de clasificación y las restricciones simples.

OWL DL: esta versión ya tiene todo el vocabulario OWL completo. Las limitaciones son que las clases no son instancias ni tipos y los tipos no son ni instancias ni clases. No permite restricciones de cardinalidad en propiedades transitivas. Posee gran expresividad sin perder las propiedades de completitud y decidibilidad.

OWL Full: esta versión también incluye todo el vocabulario de OWL, pero

interpretado de forma más amplia que en OWL DL, con la libertad proporcionada por RDF, en este caso no hay limitaciones para explotar todo su potencial. No tiene garantías computacionales.

OWL Full se considera la más completa de todas y se supone una extensión de DL que a su vez es una extensión de Lite, por lo que toda ontología correcta en OWL Lite es una ontología correcta en OWL DL, y toda conclusión correcta en OWL Lite es una conclusión correcta en OWL DL (pero no a la inversa). De la misma manera esto también ocurre con OWL DL y OWL Full respectivamente. Este lenguaje también posee funcionalidades de razonamiento para las ontologías.

2.3.5.5 Metodologías y librerías para construcción de ontologías

Construir una ontología es un proceso compuesto por una serie de actividades orientadas al desarrollo de la ontología. Existen un conjunto de propuestas de metodologías de construcción de ontologías, pero no hay un estándar para la creación de una ontología. En general, las metodologías proporcionan un conjunto de directrices que indican cómo hay que llevar a cabo las actividades identificadas en el proceso de desarrollo, qué técnicas son las más apropiadas en cada actividad y qué produce cada una de ellas.

Hay dos métodos principales que nos permite diferenciar dos tipos de ontologías según su construcción:

1) Kactus: es un método de construcción de ontologías que se basa en tomar una base de conocimiento y, a partir de ésta, determinar y conceptualizar cuales son los términos y relaciones más importantes que representaran a la ontología. (Bernaras, 1996, citado por Samper 2005).

2) Sensus: es un método que representa a las ontologías construidas a partir de una rama de una ontología más general y que es especializada para obtener una ontología nueva (Swartout, 1997, citado por Samper, 2005). Es decir, consiste en crear ontologías específicas de dominio a partir de una ontología más general.

Las principales metodologías para construir ontologías desde cero son:


- 36 -

La metodología TOVE, que se utilizó para construir la ontología TOVE

(acerca de los procesos de modelado de una empresa) (Fox, 1995; Gruninger et al., 1995; Gruninger, 1996). Está basada en la identificación de escenarios y la formulación de preguntas de competencia (Competency Questions), extracción de conceptos y relaciones relevantes y la formalización en Lógica de Primer Orden.

La metodología ENTERPRISE, que se utilize para construir la ontología ENTERPRISE (también sobre procesos de modelado de empresa) (Uschold et al., 1995; Uschold 1996; Uschold et al., 1996). Se basa en identificar el propósito para posteriormente construir, evaluar y documentar las ontologías.

METHONTOLOGY (Gómez-Pérez et al., 1996), que se utilzó para constuir,

entre otras, la ontología Chemicals (que es sobre los elementos de químicos de la tabla periódica) Es recomendada por FIPA (FIPA, 2004), y lleva a cabo su cometido mediante las tareas de especificación, adquisición de conocimiento, conceptualización, integración, implementación, evaluación y documentación de las ontologías (comentadas anteriormente).

De las metodologías anteriores, la más consensuada es METHONTOLOGY. A

continuación se describen las etapas a través de las cuales se construye una ontología según esta metodología:

Especificación, donde se identifica el objetivo y el alcance de la ontología. El

objetivo contesta a la pregunta " ¿por qué es construida la ontología? y el alcance contesta la pregunta " ¿cuáles son sus empleos intencionados y usuarios finales?"

Conceptualización, donde se describe, en un modelo conceptual, la ontología que debería ser construida para llegar a la especificación definida en el paso anterior.

Formalización, donde se transforma la descripción hallada en el paso anterior a un modelo formal.

Implementación, donde uno implementa la ontología formalizada en un lenguaje de representación de conocimiento formal.

Mantenimiento, donde se modifica y se corrige la ontología implementada.

Además de las actividades anteriores, que se deben llevar a cabo en cada etapa homónima, existen otras actividades que pueden ser realizadas durante todo el ciclo de vida de la ontología: Adquisición de conocimientos: se adquiere conocimiento sobre el dominio, ya

sea utilizando técnicas de estimulación en expertos de dominio, o haciendo referencia a bibliografía relevante.

Documentación: se describe en un documento y a lo largo de la implementación


- 37 -

lo que se hizo, cómo se ha hecho y por qué se hizo.

Evaluación: donde un técnico juzga la ontología. Existe además otra actividad que depende de la metodología:

La reutilización: que reutilicen la ontología otros, tanto como sea posible. La

mayoría de las metodologías le dan a esta actividad el nombre de “integración”.

En la figura 2.11 se puede ver un esquema que representa el orden en el que se llevan a cabo las etapas que constituyen el ciclo de vida de una ontología, según la metodología METHONTOLOGY.

Existen aproximaciones que no proponen ningún modelo de ciclo de vida

(Gómez-Pérez et al., 2004). En la siguiente figura se puede ver un esquema de ciclo de vida:

Figura 2.11 Actividades del ciclo de vida del desarrollo de una ontología


- 38 -

Figura 2.12 Ingeniería y Adquisición Ontológica (Goble, 2002)

Los métodos y metodologías no han sido creados únicamente para construir ontologías desde cero. Cuando se reutiliza una ontología puede suceder que ésta esté implementada en un lenguaje con un paradigma de representación de conocimiento subyacente, diferente a las convenciones de representación usadas por la ontología que la reutiliza, que tenga diferentes enfoques etc. Para resolver algunos de estos problemas METHONTOLOGY incluye un método de reingeniería basado en las actividades de reingeniería inversa, consistente en obtener el modelo conceptual desde el código de implementación y posteriormente la actividad de reestructuración del modelo obtenido. (Gómez-Pérez et al., 2004)

Para este proyecto se ha utilizado la metodología METHONTOLOGY, y como guía para llevar a cabo las distintas etapas de creación de la ontología se han seguido los siguientes pasos propuestos por Natalya F. y Deborah McGuinness de la Universidad de Stanford:

Determinar el dominio y alcance de la ontología.

En este punto se establece hasta dónde llegará la base de conocimientos que pensamos realizar. Normalmente se realizan preguntas de competencia y hay que considerar un dominio lo suficientemente extenso para alcanzar a responder a todas las preguntas.

Considerar la reutilización de ontologías existentes.

Dada la naturaleza de la Web semántica es importante conocer si existe ya alguna ontología de ámbito similar o incluso del mismo ámbito que nos concierne. Cualquier ontología ganará mucha calidad si se relaciona con otras.

Enumeración de los términos más importantes.

En este apartado se trata de enumerar los términos más importantes del dominio en cuestión.


- 39 -

Definición de las clases y su jerarquía.

Consiste en crear las clases y sus subclases. Existen varios posibles enfoques para desarrollar la jerarquía de clases (Uschold y Grunninger, 1996):

Un proceso de desarrollo arriba-abajo. Definir primero los conceptos más

generales e ir adentrándose en connceptos más concretos.

Un proceso de desarrollo abajo-arriba. Comenzar con lo más específico e ir generalizando.

Un proceso de desarrollo combinado. Primero se definen los conceptos más

importantes, luego los generalizamos y especializamos apropiadamente.

Definir las propiedades de las clases. Definir las propiedades más concretamente. Creación de las Instancias.


- 40 -

2.3.5.6 Herramientas para la construcción de Ontologías La principal herramienta para la construcción de una ontología son los editores. Los editores de ontologías soportan la definición de jerarquías de conceptos, la definición de atributos o propiedades de los conceptos, y la definición de axiomas y restricciones. Los editores suelen ser desarrollados para un tipo de lenguaje específico, pero muchos de ellos incorporaron módulos para soportar otros lenguajes de especificación diferentes. Se destacan los siguientes:

Ontolingua Server (Ontolingua, 2005), desarrollado en 1990 por el Laboratorio de Sistemas de Conocimiento, KSL (Knowledge Systems Laboratory) de la Universidad de Stanford, está orientado al lenguaje Ontolingua, aunque posteriormente incluyeron otros lenguajes (Fikes, 1996).

Protégé-2000 (Protégé, 2009) fue desarrollado por Stanford Medical Informatic (SMI) en la Universidad de Stanford. Es una herramienta basada en el lenguaje Java. Se trata del editor de ontologías más conocido. Sus capacidades gráficas facilitan la edición de ontologías. Actualmente es uno de los editores de ontologías más usado por investigadores para desarrollar sus ontologías, ya que es una herramienta que se actualiza con bastante regularidad y a la que se le pueden añadir módulos y plugins con nuevas funcionalidades, entre los que destaca OWLViz, herramienta de visualización gráfica de ontologías basada en grafos. Permite que la ontología desarrollada se exporte a los diferentes lenguajes de especificación más empleados actualmente (RDF, OWL, etc.). La última versión fue lanzada muy recientemente, v3.4, en marzo de 2009. El 26 de Octubre de 2008 se lanzó el editor de ontologías basado en web WebProtege v0.5 alpha, cuyo objetivo principal es soportar el proceso de desarrollo de ontologías colaborativas en entorno web.


- 41 -

Figura 2.13 El editor de ontologías Protégé-OWL.

OilEd al igual que Protégé-2000 es un editor de ontologías basado en Java, que

fue desarrollado en el contexto del proyecto europeo IST OntoKnowledge, por la Universidad de Manchester. Es un editor de ontologías de libre acceso, que permite al usuario construir ontologías usando OIL, y cuyo objetivo es ser un medio completo de desarrollo de ontologías. El modelo de conocimiento de OILEd es una extensión del sistema basado en marcos y, a diferencia de Protégé-2000, permite el uso de lenguajes de alta expresividad como DAML+OIL. Sin embargo, no soporta el desarrollo de ontología a gran escala ni el versionado, ni la migración e integración de ontologías. La herramienta contiene conceptos para el dominio del discurso como clases, slots que describen propiedades de clases, las restricciones como axiomas e instancias (Aldea et als., 2003). Los lenguajes que soporta además de DAML+OIL son RDF y RDFS.


- 42 -

Figura 2.14 Ejemplo de OILed 3.4

OntoEdit es una herramienta gráfica que soporta el desarrollo y mantenimiento

de ontologías. El modelo interno de ontología en que se basa permite desarrollar el dominio mediante el uso de clases, relaciones, axiomas, slots y atributos. Se le pueden añadir nuevas funcionalidades también a través de plugins que le aportan interoperabilidad permitiendo interactuar con otras herramientas como Sesame. Permite el uso de DAML+OIL y RDFS (Aldea et als., 2003).

Tras evaluar las herramientas anteriores y algunas más, se ha llegado a la

conclusión de que la más recomendable es Protégé. Es gratuito y de código abierto; y detrás de él hay una gran comunidad de desarrolladores y de usuarios universitarios, empresariales y gubernamentales. Y soporta el lenguaje OWL. Se ha utilizado concretamente el plugin Protégé-OWL (ver figura 2.13).


- 43 -

2.3.6. Bases de Conocimiento frente a Bases de Datos Las bases de conocimiento (KM) son una evolución de las bases de datos (BD)

tradicionales en un intento de plasmar elementos de conocimiento y la forma en que éste debe ser utilizado. Además se les dota con conocimiento sobre sí mismas: una KM “sabe lo que sabe” (Moreno, 2000).

Una BD se comopone de un esquema (estructura de datos) y los datos que se

almacenan en ella. En una KM se tiene una parte donde aparecen los términos y relaciones (TBox), que puede se comparada al esquema de las BDs; y la parte de instancias (ABox) o datos. Pero la semántica de esta parte difiere de la interpretación semántica de la instancia de los datos de las BDs. En una BD, la aunsencia de información se interpreta como información negativa, sin embargo la aunsencia de información en ABox solo indica una falta de conocimiento. Sirvase como ejemplo que la única aserción sobre PizzaDeQueso es tieneIngrediente(PizzaDeQueso, Queso), esto en el lenguaje de las BDs se entiende como que PizzaDeQueso tiene exactamente un ingrediente, que es Queso. Por el contrario en ABox, solo se puede decir que Queso es un ingrediente de PizzaDeQueso, pero no se puede afirmar nada sobre el hecho de que PizzaDeQueso tenga más ingredientes. El conocimiento en las BDs se considera como “mundo cerrado”, que asume que un hecho es falso a no ser que haya sido explícitamente declarado como cierto; de lo contrario, las DL consideran su conocimiento como “mundo abierto”. Esto da lugar a que las consultas en DL requieran un razonamiento no trivial.

2.3.7. Sistemas de almacenamiento Una de las herramientas más desarrolladas por los investigadores de la Web Semántica han sido los sistemas de almacenamiento de ontologías. Mediante estos sistemas es posible mantener las ontologías en bases de datos e ir añadiendo nueva información, y con la ayuda de razonadores probar la consistencia de la ontología. La mayoría de los sistemas de almacenamiento están orientados a descripciones de conceptos escritas en RDF, aunque algunas han ido actualizándose a los últimos lenguajes de especificación. Se destacan las siguientes herramientas en esta área:

Sesame (Broekstra, 2002) es un repositorio para RDF-Schema desarrollado por Aidministrator Nederland bv. Tiene funciones para añadir y eliminar información escrita en RDF en los repositorios, para ser almacenada en cualquier tipo de base de datos (MySQL, Oracle etc.). Soporta los lenguajes de consulta RQL, RDQL y SeRQL, para acceder al conocimiento.

KAON Tool (KAON, 2005) desarrollado por la infraestructura KAON (Karlsruhe Ontology) Semantic Web, implementa un interfaz independiente del sistema en el que se almacenarán las ontologías, ya sean cualquier base de datos o un fichero de texto. Implementa un API para leer las descripciones de los recursos, emplea RQL para realizar consultas y soporta tanto ontologías DAML + OIL como RDF.


- 44 -

Jena (Jena, 2007) es una colección de herramientas desarrollado por Hewlett-

Packard para la Web semántica. La primera versión tenía capacidades de razonamiento muy limitadas y principalmente daba soporte a RDF. En la segunda versión ya se incluyó una API de Java para trabajar con ontologías y soporte del lenguaje OWL. En la actualidad Jena2 incluye:

▪ ARP: un parser de RDF. ▪ API de RDF. ▪ API de ontologías escritas en OWL, DAML y RDF Schema. ▪ Subsistema de razonamiento. ▪ Lenguajes de consultas RDQL y SPARQL. ▪ Subsistema de persistencia que trabaja con MySQL, Oracle y

PostgreSQL.

La gran ventaja de Jena2 es que es una biblioteca de Java, y todos nos manejamos bien con este lenguaje. Debido a todas estas ventajas, y principalmente porque soporta OWL, en este proyecto se utiliza Jena2 para manejar la ontología desde la aplicación web.

2.3.8. Razonadores Los razonadores son una de las herramientas más importantes utilizadas con las ontologías, sirven para realizar inferencia (deducir información adicional), a través de los conceptos y en algunos casos las instancias, para obtener nuevo conocimiento. Generalmente difieren en el lenguaje formal en el que se especifica el conocimiento, así como los lenguajes de consulta que puedan utilizar. Un motor de razonamiento en base a Lógica Descriptiva, asocia dos mecanismos internos en su entendimiento del conocimiento. El primero denominado TBox (caja terminológica) y un segundo llamado ABox (caja de aserciones). En general, la TBox contiene sentencias describiendo conceptos jerárquicos (p.e., relaciones entre conceptos) mientras la ABox contiene sentencias ground indicando a donde pertenecen los individuos en la jerarquía (p.e., relaciones entre individuos y conceptos). Esta separación es puramente operativa, ya que estas distinciones permite a un razonador de lógica descriptiva operar de mejor forma.

La figura 2.14 muestra la arquitectura de un Sistema Terminológico (marco de investigación de la lógica descriptiva) se diferencian tres subsistemas: la base de conocimiento, un mecanismo o sistema de inferencia y un interfaz. En la base de conocimiento se almacena la información sobre el dominio organizada utilizando una jerarquía de clases y relaciones entre ella.

El sistema de inferencia se utiliza para razonar sobre la base de conocimiento. El conjunto de razonamientos que se pueden realizar está directamente relacionado con la expresividad de la lógica descriptiva que se esté utilizando y finalmente el interfaz que permite la interoperabilidad con el Sistema Terminológico.


- 45 -

Los principales razonadores o sistemas de inferencia basados en lógica descriptiva actualmente son:

RACER (Renamed ABox and Concept Expression Reasoner) (RACER, 2008) desarrollado por Ralf Möller y Volker Haarslev en 1999, pero que ha sido renovado periódicamente hasta la fecha (la última versión comercial es la 1.9.0 y se lanzará una nueva versión Racer-Pro 2.0 durante el 2009). Es un razonador diseñado para la Web Semántica. Permite la inferencia tanto en conceptos como en instancias, soporta ontologías escritas en RDF, RDF Schema, Daml y OWL (apenas tiene restricciones con estos lenguajes) y posee un lenguaje de consulta sencillo para la inferencia de instancias. Puede ser utilizado tanto por OilEd como por Protégé tanto para comprobar la consistencia de la ontología, como para hacer consultas sobre el conocimiento.

Pellet (Pellet, 2003) Pellet es un razonador de OWL-DL basado en Java. Puede ser utilizado conjuntamente con bibliotecas del API de Jena o del OWL. Mediante su uso es posible validar, comprobar la consistencia de ontologías, clasificar la taxonomía y contestar a un subconjunto de consultas RDQL (conocido como consultas a ABox en terminología del DL). Se trata de una razonador DL basado en los algoritmos tableaux desarrollados para DL expresiva. Soporta todas las construcciones del OWL DL incluyendo las relacionadas con los nominales, es decir, owl:oneOf y owl:hasValue.

Los razonadores basados en lógica descriptiva deben de poseer la suficiente expresividad para poder permitir que el conjunto de constructores que forman parte de los lenguajes de ontologías sean soportados, y poder permitir ambos tipos de inferencia, tanto de clasificación como de chequeo de instancias.

Figura 2.15 Arquitectura de un Sistema Terminológico (Horrocks, 2001).


- 46 -

2.3.9. Lenguajes de consulta

Se destacan los siguientes:

RDQL (RDF Data Query Language) fue desarrollado por HP para que fuese el lenguaje de consulta para RDF en los modelos de Jena, con la idea de convertirse en un modelo de consulta orientado a datos por ser una aproximación totalmente declarativa. Debido a esto, solo se pueden hacer consultas sobre la información que hay en el modelo, por lo que la inferencia o razonamiento no es posible. Como RDF provee una estructura de grafos, donde los nodos son recursos o literales, RDQL permite especificar patrones que son mapeados contra las tripletas (sujeto, predicado, objeto) del modelo para retornar un resultado. Además de la desventaja de no permitir realizar ninguna inferencia, la utilización de filtros para obtener resultados es muy limitada. Las ventajas son la sencillez de manejo, ya que solo hace falta tener claro qué tripleta (sujeto, predicado, objeto) se quiere preguntar, y otra de las ventajas son la facilidades de integración con Java, debido a que ha sido implementado por los mismos desarrolladores de Jena.

SeRQL (Sesame RDF Query Language) es un lenguaje de consulta en RDF o

RDF Schema que en la actualidad está siendo desarrollado como parte de Sesame. Combina los mejores aspectos de otros lenguajes de consulta (p.ej. RQL, RDQL, N3, etc.) con algunos añadidos nuevos propios. Algunas de las funcionalidades más importantes que ofrece SeRQL son: Transformación de grafo Soporte de RDF Schema Soporte de Datatype de XML Schema Sintaxis expresivas para los path ( o URI) Matching opcional de path (o URI)

Este lenguaje de consultas posee tres componentes importantes: URIs, literales y variables. Una de las diferencias de este lenguaje respecto al resto es la de presentar dos formas diferentes de hacer la consulta, la devolución de tablas con los posibles valores que pueden tomar las variables en nuestra consulta (“Select”, común al resto de lenguajes), y devolviendo el resultado en la forma de subgrafo que nosotros le sugerimos, almacenando la información del resultado en un grafo RDF (son consultas conocidas como “Construct”).

DQL (Daml Query Language) se trata de un lenguaje formal y protocolo para conducir el diálogo entre un agente cliente que realiza consultas y un agente que contesta los requerimientos, haciendo uso para ello de conocimiento representado en DAML + OIL. La diferencia principal de este lenguaje con el resto reside en la sintaxis para la descripción de las consultas. En este caso se deben de seguir los patrones de


- 47 -

Query y Answer descritos por una ontología dql.daml. Esta ontología describe como deben de estar formadas tanto las consultas como las respuestas. Es un lenguaje de consulta y no de inferencia, y respecto a éstos tiene la ventaja de que está preparado para manejar conocimiento descrito en DAML + OIL. Sin embargo, las herramientas que implementan este lenguaje han sido escasas. DQL es soportado por el razonador JTP, que está preparado para admitir consultas mediante mensajes SOAP y retornar los resultados en el correspondiente mensaje de respuesta SOAP.

OWL-QL es una actualización del lenguaje anterior (DQL). En este caso, se

trata de un lenguaje formal y protocolo para conducir el diálogo entre un agente cliente que realiza consultas y un agente que contesta los requerimientos, haciendo uso para ello de conocimiento representado en OWL. Intenta convertirse en un estándar, y para ello tiene en cuenta una serie de factores dentro de la Web Semántica: La previsión de que incluirá muchos tipos de servicios petición-respuesta

con acceso a muchos tipos de información representados en muchos formatos. Por lo que se debe lograr manejar esta heterogeneidad.

El hecho de que algunos servidores contengan solo información parcial sobre algún tópico y por tanto serán incapaces de manejar o dar respuesta a ciertos tipos de requerimientos. Se pretende que los propios protocolos de consulta puedan proveer algún medio de transferencia de resultados parciales.

La idea de que una consulta o requerimiento especificada en un lenguaje de la Web Semántica necesita dar soporte a requerimientos que no incluyan una especificación de la base de conocimiento, de igual manera que los usuarios de un navegador en Internet, no necesitan describir que portales web se han de considerar cuando realizan una búsqueda. Se pretende que los propios servidores sean capaces de encontrar las apropiadas bases de conocimiento.

El hecho de que el conjunto de notaciones y sintaxis usadas en la Web se ya demasiado extenso, y varias comunidades tengan diferentes preferencias, y por tanto ninguna universal. Se debe lograr que los aspectos esenciales del lenguaje sean independientes del conjunto de su sintaxis.

Por último, la premisa de que en la Web Semántica, los lenguajes declarativos usados para representar en la Web tenga una semántica definida formal y lógica. Este es el caso de OWL y sus predecesores.

OWL-QL tiene en cuenta todos estos factores e intenta subsanar todas las deficiencias que hasta ahora se habían encontrado en los demás lenguajes de requerimientos.


- 48 -

RQL (RDF Query Language) es un lenguaje de consulta para RDF y RDF

Schema basado en OQL (Object Query Language). RQL permite navegar por los grafos que hay en el modelo RDF y proporciona un mecanismo para preguntar y seleccionar los nodos del modelo que queramos recuperar. La característica más destacable de este lenguaje es que posee construcciones propias específicas para las relaciones semánticas dentro del RDF Schema, como pueden ser las relaciones de clase/instancia, clase/propiedad o el dominio y rango de una propiedad, por lo que resulta más fácil recuperar información de los nodos del modelo.

SPARQL es un lenguaje de consultas para grafos RDF propuesto recientemente

por W3C. Ofrece a los desarrolladores y usuarios finales un camino para presentar y utilizar los resultados de búsquedas a través de una gran variedad de información como puede ser datos personales, redes sociales y metadatos sobre recursos digitales como música e imágenes. SPARQL también proporciona un camino de integración sobre recursos diferentes. Es un lenguaje para hacer búsquedas en fuentes de datos donde los datos se almacenan en RDF o, al menos, pueden ser vistos como RDF. Es muy rápido y permite obtener resultados de las búsquedas como grafos de RDF. Permite: Extraer información en diversas formas, incluyendo URIs. Extraer subgrafos RDF. Construir nuevos grafos RDF basados en la información de los grafos

consultados.

CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO

- 49 -

3. METODOLOGÍA Y PLAN DE TRABAJO

3.1. Planificación y gestión del proyecto

La gestión de un proyecto de software comienza con un conjunto de actividades que en su totalidad se denominan planificación del proyecto. Antes de empezar con el desarrollo de un proyecto se debe estimar el trabajo que habrá que realizar, los recursos que se requerirán y el tiempo que durará el proyecto. Una vez completadas estas actividades se debe establecer un plan de proyecto que defina tareas y fechas clave de la ingeniería del software, que identifique el responsable de cada tarea y especifique las dependencias entre tareas que pueden ser determinantes en el progreso (Pressman, 2007).

El objetivo de la planificación del proyecto de software es proporcionar un

marco de trabajo para que el gestor del proyecto pueda realizar estimaciones razonables de recursos, coste y programa de trabajo.

La primera de las actividades de planificación es la estimación. Esta actividad

intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema basado en software.

La estimación comienza con una descripción del ámbito del proyecto. Luego, se

descompone el problema en un conjunto de problemas más pequeños, y se estima el esfuerzo para realizar cada uno de éstos empleando datos históricos y la experiencia como guías (Pressman, 2007).

En la primera parte de esta sección se muestra el proceso de planificación

realizado para llevar a cabo este proyecto de manera que el tiempo se utilice de forma eficiente. Se trata de clarificar el orden de las tareas, y estimar el tiempo necesario para llevarlas a cabo (Dawson y Martín, 2002).

Y en la segunda parte se realiza la asignación de los recursos requeridos para el

desarrollo de este proyecto, así como la estimación del esfuerzo y el dinero que va a costar realizar el proyecto.


- 50 -

3.1.1. Definición de recursos

Los recursos necesarios para completar el esfuerzo de desarrollo de este proyecto se van a determinar en dos grandes categorías de los recursos de ingeniería del software: el personal y el entorno de desarrollo (hardware y herramientas de software).

3.1.1.1 Recursos humanos

Teniendo en cuenta la naturaleza de este proyecto, al tratarse de un proyecto académico y a la vez desarrollado para una empresa, los perfiles de los miembros del grupo de trabajo que intervendrán serán los siguientes:

Director y Codirector de proyecto.

El director (Dr. Javier Samper Zapater) tendrá el papel de tutor académico.

Como tutor académico se ocupará del contenido académico del proyecto. Aconsejar sobre las áreas a desarrollar, las herramientas y técnicas a emplear, así como asegurarse de que se está elaborando la documentación adecuada.

La Codirectora (Dª María José Núñez) desempeñará la función de manager en la empresa. Dirigirá el proyecto en el sentido más general. Se preocupará del progreso global, asegurándose de que se estén consiguiendo los objetivos parciales que se han propuesto.

Jefe de proyecto (D. Miguel Ángel Abián)

Sus principales funciones serán estimar el esfuerzo necesario para concluir el proyecto, seleccionar la estrategia apropiada para desarrollarlo, así como supervisar el proyecto y dirigirlo durante todas las fases del mismo, asegurándose de que se cumple el tiempo y requisitos establecidos.

Analista y Programador (Mouna Ziouziou)

En el desarrollo de todo sistema informático los principales componentes son el análisis y el diseño del sistema. El análisis del sistema es el proceso de recopilar e interpretar los requisitos y diagnosticar los posibles problemas que puede haber con la meta de mejorar la perspectiva que se tiene del sistema y como consecuencia realizar un buen diseño. El diseño es el proceso utilizado para definir cómo se va a desarrollar el sistema, qué módulos lo formarán y cómo de comunicarán entre sí, cuál será la estructura del código a implementar, etc. El analista será el responsable de mantener entrevistas y sesiones de trabajo con los responsables de la organización y usuarios para establecer los requisitos del sistema, y en base a esto realizar un análisis y diseño coherentes del sistema a desarrollar. El programador será el encargado de la implementación del código del sistema basándose en el diseño realizado previamente; así como de realizar la carga inicial de datos y las pruebas del sistema.


- 51 -

3.1.1.2 Recursos del entorno

Como en todo proyecto de software, el entorno que lo soporta - denominado

entorno de ingeniería del software (EIS) - incorpora hardware y software. El hardware proporciona una plataforma que soporta las herramientas (software) que se van a utilizar para producir los productos de trabajo basados en una buena práctica de la ingeniería del software. Para este proyecto, el hardware que se empleará será:

Ordenador portátil Pentium Centrino. Ordenador portátil Pentium Core Duo. Material de imprenta y material fungible.

En cuanto al software necesario para llevar a cabo este proyecto será:

- Para el desarrollo de la ontología:

Editor de ontologías (Protégé 2000). Razonador (Racer Pro, Pellet,...).

- Para el desarrollo de la aplicación: Interfaz para el modelado del sistema en UML (Enterprise Architect,

Poseidón...). Entorno de desarrollo (Eclipse, Netbeans,...). API para trabajar con ontologías (Jena, Sesame...).

- Para documentar el proyecto: Procesador de texto (MS Office 2007). Herramienta de planificación para desarrollar un cronograma con la

planificación temporal del proyecto (MS Project).

Más adelante se verá la estimación de los costes asignados a los elementos hardware y software que se han mencionado en este apartado.

3.1.2. Planificación temporal

La planificación temporal consiste en desarrollar un plan para la realización del proyecto. Tiene dos funciones: clarificar el orden de las tareas, y estimar el tiempo necesario para llevarlas a cabo (Dawson y Martín, 2002).

La estimación del esfuerzo necesario se realiza en base a la experiencia

adquirida en la realización de sistemas anteriores que tengan cierta similitud con el sistema a desarrollar. Sin embargo, la duración de cada tarea viene determinada por varios factores: la complejidad, la disponibilidad, la información necesaria, etc. Para ese proyecto habrá que tener en cuenta lo siguiente:


- 52 -

El recurso Analista/Programador tendrá una dedicación de 4 horas al día, cinco días a la semana. Teniendo en cuenta que el proyecto tendrá una duración de aproximadamente un año, la disponibilidad inicial es de 960 horas.

Durante toda la duración del proyecto se contará con la ayuda del director y del jefe de proyecto, por lo que también habrá que tener en cuenta las horas que éstos le dediquen.

Descomposición del proyecto en subtareas

El primer paso en el proceso de planificación es la división del trabajo. Se trata de descomponer el proyecto en sus objetivos principales y luego dividir éstos sucesivamente, hasta identificar el trabajo de desarrollo que se necesita llevar a cabo.

Cuanto más se descomponga el problema más correcta será luego la estimación.

Aunque no conviene perder mucho tiempo intentando hacer una planificación lo más exacta posible. Se trata de alcanzar un equilibrio que solucione las necesidades del proyecto.

Antes de descomponer el proyecto conviene establecer el propósito principal del

mismo y los objetivos. De modo que teniendo en cuenta lo establecido en el apartado de Objetivos de esta memoria, se descompone el proyecto en las subtareas de la figura 3.1.

En la primera descomposición que se realiza se identifican 7 tareas que se corresponden con los objetivos principales. A continuación se describen brevemente la funcionalidad y las subtareas de cada una de estas actividades:

1) Puesta al día bibliográfica Se trata de recopilar y analizar la información disponible sobre el tema del proyecto. Se divide en dos fases: búsqueda y revisión (Dawson y Martín, 2002). La búsqueda bibliográfica consiste en: buscar, ordenar, gestionar y asimilar

la información disponible. Es importante saber qué se pretende buscar exactamente para no perder mucho tiempo leyendo información que no es relevante en nuestro proyecto. Hay que saber gestionar la información que se va recopilando, esto facilitará el camino para la siguiente fase.

La revisión bibliográfica consiste en: comprender lo leído y extraer las ideas principales para el propósito de nuestro proyecto.

2) Análisis y desarrollo de la ontología.

Esta tarea constituye el primero de los objetivos principales de este proyecto, que es la obtención de una ontología del dominio del mueble que esté basada en el estándar funStep. Incluye todo el proceso de definición de la ontología (adquisición de conocimiento, especificación, conceptualización, formalización e implementación), la creación de instancias y la prueba de la ontología. El resultado de todo esto constituye una base de conocimiento a la cual accederá la


- 53 -

aplicación de búsqueda que se va a desarrollar. Se descompone en las siguientes actividades:

Análisis de requisitos. Se delimitarán los requisitos para el desarrollo de la ontología.

Análisis del modelo de datos ISO funStep. Esta tarea consistirá en el estudio del modelo de datos ISO funStep, para extraer aquellos conceptos que sean relevantes para la ontología a desarrollar. Pues uno de los requisitos establecidos para la creación de la ontología es basarse en el estándar internacional funStep.

Adquisición de conocimiento. Esta fase consistirá en mantener entrevistas

con expertos en el sector y recopilar información de las distintas fuentes disponibles (normas, catálogos, libros, enciclopedias, etc.).

Definición de la ontología. Se definirán los conceptos y relaciones

siguiendo una metodología de desarrollo de ontologías. Se crearán instancias y se probará la ontología.

3) Análisis del sistema.

Se recopilarán y se interpretarán los requisitos para el desarrollo del buscador. Se determinarán los casos de uso del sistema, así como el comportamiento y la funcionalidad del mismo. Finalmente, se analizarán los componentes que va a necesitar la interfaz de usuario para manejar de forma sencilla los diferentes casos de uso establecidos.

4) Diseño del sistema.

Se descompondrá el sistema en los subsistemas que serán necesarios para construir e implementar los diferentes casos de uso definidos en la fase de análisis.

5) Implementación

Se realizará la codificación de las estructuras definidas en las fases de análisis y diseño en algoritmos.

6) Prueba del sistema. Como en todo desarrollo de un sistema software, es necesario realizar pruebas para detectar posibles fallos y asegurarse del buen funcionamiento del sistema desarrollado.

7) Completar la redacción de la memoria. Se intenta dejar reflejado todo el trabajo realizado.


- 54 -

Figura 3.1 Descomposición del proyecto en tareas


- 55 -

Estimación de tiempos Una vez descompuesto el proyecto en tareas, se pueden llegar a hacer

predicciones del esfuerzo necesario para completar dichas actividades, y consecuentemente, para completar el proyecto en su totalidad.

Utilizando las estructuras de la figura 3.1, el tiempo estimado para completar las

tareas se especifica en la tabla 3.1.

Actividad Duración estimada Puesta al día bibliográfica 240 horas Análisis y desarrollo de la ontología 260 horas Análisis del sistema 80 horas Diseño del sistema 8 horas Implementación 100 horas Pruebas del sistema 20 horas Completar la memoria 160 horas Total 1020 horas

Tabla 3.1 Estimación de tiempos del proyecto

Las horas estimadas que dedicará cada uno de los recursos humanos de los que se dispone serán las siguientes:

Recurso Nombre Horas Director del proyecto Javier Samper 32 Codirectora del proyecto Mª José Núñez 20 Jefe de Proyecto Miguel Ángel Abián 96 Analista/Programador Mouna Ziouziou 872 Total 1020

Tabla 3.2 Estimación de tiempos del proyecto

Identificación de hitos El siguiente paso en el proceso de planificación del proyecto es la identificación de hitos. Los hitos son unos objetivos intermedios en el proceso de desarrollo del proyecto, y constituyen los pasos previos que llevan a conseguir la meta final (Dawson y Martín, 2002).

Para identificar los hitos hay que centrarse en la división que se ha realizado de la estructura del proyecto y extraer de ella los puntos clave en el desarrollo del mismo. En este caso, los puntos clave que permiten tener constancia del progreso del proyecto son claramente los siguientes:

Finalización de la investigación bibliográfica (hito 1; H1) Fin de creación de la ontología de muebles y afines (hito2; H2) Finalizar el desarrollo de la aplicación de búsqueda (hito3;H3)


- 56 -

Finalización de la escritura de la memoria (hito4; H4) A la hora de realizar la planificación temporal de un proyecto hay que tener en

cuenta la ordenación temporal de las actividades ya que habrá algunas tareas que necesitarán de los resultados obtenidos en fases anteriores en el tiempo o de determinados recursos que en ese momento estarán siendo utilizados por otras actividades. La planificación por lo tanto, se encargará de definir el orden correcto de ejecución y la duración asociada a cada tarea.

3.1.2.1 Diagrama de Gantt

En la figura 3.2 se muestra el diagrama de Gantt que representa la planificación temporal de este proyecto. El eje de abscisas se usa para la distribución del tiempo, representa el calendario de ejecución del proyecto; y en el eje de ordenadas se representan las actividades. Cada actividad se representa mediante una barra horizontal cuya longitud es proporcional a la duración estimada de la actividad.


- 57 -

Figura 3.2 Diagrama de Gantt


- 58 -

3.2. Estimación de costes del proyecto

La realización de cualquier proyecto implica una serie de costes directos e indirectos.

Los costes directos son aquellos que son imputables directamente al proyecto y consecuencia del mismo, como son: costes de personal, subcontrataciones, material, equipo, viajes, estancias y otros gastos adicionales (adquisición de documentación, comidas, o ciertos gastos de representación).

Los costes indirectos se entienden como aquellos que la empresa debe ingresar a

través de los proyectos que realice y en los cuales ésta incurre, realice o no proyectos. Se conocen también como los costes generales, tales como: alquiler y amortización del inmueble, costes de suministros, de limpieza, mensajería, costes laborales asociados a personal no productivo del proyecto (administración, directivos, etc.).

A pesar de que en un proyecto académico pierde importancia el proceso de

estimación de costes ya que el propósito buscado no es obtener beneficios económicos, se va a realizar igualmente puesto que es una buena práctica para la realización de futuros proyectos.

Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones,

pero lo viable es: el uso de técnicas de descomposición y la utilización de uno o más modelos empíricos para estimación de costo y esfuerzo. Las técnicas de descomposición asumen un enfoque de “divide y vencerás” respecto de la estimación del proyecto de software. Al descomponer un proyecto en funciones principales y actividades de ingeniería del software relacionadas, las estimaciones de costes y esfuerzo se pueden hacer en forma escalonada. Los modelos de estimación empírica sirven para completar las técnicas de descomposición y ofrecer un enfoque de estimación potencialmente valioso por su propio derecho (Pressman, 2007).

Teniendo en cuenta lo anterior, en este proyecto se realiza en primer lugar, una

estimación mediante una técnica de descomposición basada en el proceso, para estimar el esfuerzo requerido, y en consecuencia, el coste del proyecto. Y posteriormente, una estimación basada en el modelo empírico COCOMO II (Constructive Cost Model, Modelo Constructivo de Costos), que calcula el esfuerzo y el coste del desarrollo del software en función del tamaño del programa expresado en líneas de código (LDC).

3.2.1. Coste Laboral

El coste laboral lo constituyen los gastos relacionados con el trabajo realizado por las personas físicas, y viene dado por el número de horas trabajadas junto con la categoría profesional a la que pertenece cada trabajador. A la hora de estimar el coste que supone una persona a la empresa, no solo se considera el sueldo que éste recibe, sino también la parte proporcional de los gastos adicionales en los que incurre la empresa (costes sociales). En la siguiente tabla se muestra el coste por hora que se ha considerado para cada una de las categorías participantes en este proyecto.


- 59 -

CATEGORÍA COSTE POR HORA

Director de Proyecto 80 €

Codirector de Proyecto 70 €

Jefe de Proyecto 60 €

Analista / Programador 40 €

Tabla 3.3 Costes por hora de cada categoría

Para poder estimar el esfuerzo requerido por cada uno de los participantes para llevar a cabo el proyecto en su totalidad, conviene usar alguna de las técnicas existentes. En el siguiente apartado se realiza esta estimación utilizando la técnica de descomposición basada en el proceso. 3.2.1.1 Técnica basada en el proceso

La técnica más común para estimar un proyecto es basar la estimación en el proceso que se empleará (Pressman, 2007). Se trata de descomponer el proyecto en un conjunto de tareas de forma que siga el proceso elegido para el desarrollo del sistema y estimar el esfuerzo requerido para lograr cada tarea. Por lo tanto, en base a la estimación de horas calculadas en el apartado anterior de Planificación Temporal y los costes por horas arriba indicados la estimación de coste del personal la siguiente:

Categoría Horas Coste por hora Total Director de Proyecto 32 80 € 2.560 € Codirector 20 70 € 1.400 € Jefe de Proyecto 96 60 € 5.760 € Analista/Programador 872 40 € 34.880 € Total 1020 42,35 € 43.200 €

Tabla 3.4 Costes de personal

Una vez calculados los costes de personal, se va a proceder a estimar los costes materiales. Éstos corresponden a los gastos de material informático tanto software como hardware, gastos de viajes, gastos de representación y otros gastos como por ejemplo de material de oficina.

Subcontrataciones

No se ha necesitado de ninguna subcontratación para llevar a cabo el proyecto.


- 60 -

Material y equipo

Teniendo en cuenta los recursos de entorno que se van a emplear – citados en el apartado de Asignación de recursos - los costes estimados son los siguientes:

Gatos Coste PC portátil Intel Pentium Centrino 1.000€ PC portátil Intel Pentium Core Duo 1.000€ MS Office 2007 100€ Material de imprenta y material fungible 50 € Total 2.650€

Tabla 3.5 Costes de material y equipo

El resto de recursos son de libre licencia y por eso no aparecen en la tabla

anterior.

Viajes y estancias

No se ha realizado ningún viaje para el desarrollo del proyecto.

Otros costes

No se ha definido ningún otro gasto extra.

Coste Total

Una vez obtenidos el coste de personal y el coste de recursos, tanto hardware como software, ya se puede calcular el coste total del proyecto. Para ello se añadirá a la suma de estos costes un 10% más por si surgen imprevistos a lo largo del desarrollo del proyecto.

Coste total = 43.200 + 2.650 = 45.850€ Coste final = 45.850 + 10% (4.585) = 50.435€ El resultado de la estimación de costes para este proyecto asciende a la

cantidad de (50.435 + 16%) 58.504,6€ IVA incluido.


- 61 -

3.2.1.2 El modelo COCOMO 2

El COCOMO (Constructive Cost Model) es un modelo empírico para estimar el esfuerzo, la calendarización y los costos de un proyecto informático. Se elige el modelo COCOMO para estimar los costes de este proyecto por las siguientes razones:

1. Está bien documentado, es de dominio público y lo apoyan el dominio público y las herramientas comerciales.

2. Se ha utilizado y evaluado muy ampliamente.

3. Tiene una gran tradición desde su primera versión en 1981 (Boehm, 1981), pasando por un refinamiento para el desarrollo de software en ADA (Boehm y Royce, 1989), hasta su versión COCOMO II, publicada en 1995 (Boehm et al., 1995).

COCOMO II es una evolución del modelo de estimación COCOMO original, el cual se convirtió en uno de los modelos de estimación de costo de software más ampliamente utilizados y estudiados en la industria (Boehm, 1996; Boehm, 2000). Actualmente derivó a COCOMO 2000, en el que nos basaremos en la estimación realizada a continuación. Éste considera diferentes enfoques para el desarrollo de software como el de construcción de prototipos, el desarrollo por composición de componentes, la utilización de 4GLs, etc. Los niveles del modelo no reflejan simplemente estimaciones detalladas con complejidad creciente. Los niveles se asocian a las actividades en el proceso del software, por lo que las estimaciones iniciales se llevan a cabo al inicio del proceso y las estimaciones más detalladas se llevan a cabo después de definirse la arquitectura del sistema. Se va a emplear el nivel postarquitectónico ya que hace una estimación razonablemente precisa del tamaño del software. Se utilizan 17 atributos que reflejan la capacidad del personal, el producto y las características del proyecto, para refinar el cálculo del esfuerzo final. Los costes laborales (en persona-mes) se obtienen mediante la siguiente expresión:

P = A x ESLOCB x M + PMm

A continuación se muestra cómo se calculan los distintos parámetros de los que consta la expresión:

A: Este parámetro viene dado por Boehm, que propone que sea de 2,5.

ESLOC: Líneas de código nuevo, se calcula de la siguiente manera:

ESLOC = ASLOC x (AA + SU + 0,4DM + 0,3CM + 0,3IM) / 100


- 62 -

Siendo:

ASLOC: Miles de líneas de código reutilizables que deben modificarse.

AA: Factor que refleja los costos de valoración inicial acerca de la posible reutilización del software (0-8).

SU: Factor que se basa en el costo de comprensión del software (10-

50)

DM: Porcentaje de modificación del diseño

CM: Porcentaje de código que se modifica

IM: Porcentaje del esfuerzo original requerido para integrar el software utilizado.

ESLOC = 3 x (5 + 30 + 0,4*0.4 + 0,3*0.3 + 0,3*0.8) / 100 = 1,06

B: Refleja el esfuerzo creciente requerido al incrementarse el tamaño del proyecto. Este exponente se estima considerando 5 factores de escala que pueden tomarse de seis valores que van desde muy bajo hasta extraalto (5 a 0). Se calcula de la siguiente manera: B = (Precedentes + Flexibilidad del desarrollo + Resolución de la arquitectura + Cohesión del equipo + Madurez del proceso) / 100 + 1,01

Precedentes: Refleja la experiencia previa de la organización con este tipo de proyectos. Muy bajo significa sin experiencia previa, y extraalto significa que la organización está completamente familiarizada con este dominio de aplicación. En este caso es un proyecto nuevo por lo que se da valor Bajo (4).

Fiabilidad de desarrollo: Refleja el grado de flexibilidad en el proceso de desarrollo. Muy bajo significa que se utiliza un proceso prescrito, y extraalto significa que el cliente establece solo metas generales. Se da valor Muy alto (1) ya que el cliente no define el proceso a utilizar.

Resolución de la arquitectura: Refleja la amplitud del análisis de riesgos

que se lleva a cabo. Muy bajo significa poco análisis. Extraalto significa un análisis de riesgo completo y detallado. Se da valor Bajo (4) porque no existe suficiente tiempo en la calendarización para análisis de riesgos.

Cohesión del equipo: Refleja qué tan bien se conocen entre ellos los

miembros del equipo y qué tan bien trabajan juntos. Muy bajo significa interacciones muy difíciles, y extraalto significa un equipo integrado y efectivo sin problemas de comunicación. En este caso no existe información ya que se crea un nuevo equipo – valor Nominal (3).


- 63 -

Madurez del proceso: Refleja la madurez del proceso de la organización.

B = (4 + 1 + 4 + 3 + 3) / 100 + 1,01 = 1,16

M: Es un multiplicador que se basa en un conjunto simplificado de 7 conductores de proyectos y procesos en los que se incluye la fiabilidad y complejidad del producto (RCPX), la reutilización requerida (RUSE), la dificultad de la plataforma (PDIF), la capacidad del personal (PERS), la experiencia del personal (PREX), la calendarización (SCED) y los recursos de apoyo (FCIL). Éstos se pueden estimar directamente sobre una escala de seis puntos, donde 1 corresponde a valores muy bajos de estos multiplicadores y 6 corresponde a valores muy altos. Los atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitectónico son de cuatro clases:

1. Atributos del producto:

RELY: Fiabilidad requerida del software. Sirve para indicar el nivel de consecuencias que tendrá un fallo del sistema en el cliente. Si se da un valor bajo, el fallo no afecta demasiado al cliente, pero si se da un valor muy alto es porque el fallo puede tener consecuencias mortales en el cliente. Para este proyecto se estima un valor nominal para este atributo, ya que no requiere una fiabilidad crítica, pero sí que se debe asegurar un buen funcionamiento del sistema.

DATA: Tamaño de la base de datos. En este caso, la base de datos se generará de forma automática a partir del modelo ontológico creado. Contendrá tanto el modelo ontológico como las instancias que se deseen almacenar, y se espera tener una cantidad considerable de instancias ya que el sistema desarrollado es un buscador. Por lo que se tomará un valor muy alto.

CPLX: Complejidad de los módulos del sistema. Mide si el

software desarrollado emplea un código con múltiples estructuras de control, cálculos, operaciones dependientes de dispositivos… En este caso aunque las operaciones no dependan de dispositivos, construir una ontología donde se mantenga la coherencia y la consistencia puede resultar un código algo complejo. Además de la complejidad de la estructura RDF, consultas y librerías utilizadas. Por ello se le da valor alto a este atributo.

2. Atributos de la computadora:

TIME: Limitaciones en el tiempo de ejecución. Los tiempos de proceso no son demasiado elevados por lo que se toma un valor nominal.


- 64 -

STOR: Restricciones de memoria principal. Debido a que se requiere que toda la información esté almacenada en memoria se ocupa bastante espacio en memoria principal por lo que se aplica valor alto.

PVOL: Volatilidad de la máquina virtual. La máquina virtual se considera el conjunto de hardware y software que el producto emplea para desarrollar sus funciones. Dado que la mayoría de las herramientas utilizadas son estándares que aún se encuentran en estado de borrador, se aplica un alto grado de volatilidad.

3. Atributos de personal:

ACAP: Capacitación de los analistas. Atributo que sirve para medir la

capacidad que poseen los analistas implicados en el proyecto para el análisis, eficiencia y capacidad para poder llevarlo a cabo. Se dará un valor nominal a este atributo, ya que se posee algunos conocimientos para poder llevar a cabo esta tarea, pero se carece de experiencia en trabajos tan amplios.

AEXP: Experiencia en aplicaciones. Sirve para conocer qué capacidad posee el personal para emplear las herramientas implicadas en el desarrollo del producto. En mi caso, se tenía un nivel bajo al comenzar el desarrollo del producto.

PCAP: Capacitación de los programadores. Sirve para medir la

habilidad del personal para programar. Se da un valor alto, ya que se ha acumulado experiencia en la programación a lo largo de la carrera.

LTEX: Experiencia en el lenguaje de programación. Si el lenguaje

empleado en la implementación del producto es desconocido para el personal, el desarrollo se hace más complejo. En este caso, se tiene experiencia adquirida a lo largo de la carrera en el lenguaje de programación empleado para el desarrollo del Interfaz, sin embargo la experiencia en lenguajes de ontologías y en lenguajes de consulta empleados era nula, por lo que se da un valor bajo a este atributo.

4. Atributos de proyecto:

TOOL: Uso de herramientas para el desarrollo del software. En este caso han sido necesarias herramientas modernas, por lo que se da un valor alto.

SCED: Limitaciones en la planificación. Sirve para indicar si el desarrollo del producto está dentro de las limitaciones de tiempo que se programó al principio del desarrollo. En este caso se le da un valor nominal.


- 65 -

Estos atributos, como se ha indicado, sirven para actuar como multiplicadores del coste calculado anteriormente. La siguiente tabla muestra los valores que se le ha dado a cada atributo y el valor numérico asociado que se debe aplicar como multiplicador:

Atributo Valor Valor Multiplicativo RELY Nominal 1 DATA Muy alto 1.30 CPLX Alto 1.15 TIME Nominal 1 STOR Alto 1.21 PVOL Alto 1.15 ACAP Nominal 1 AEXP Bajo 1.13 PCAP Alto 0.86 LTEX Bajo 1.15 TOOL Alto 0.91 SCED Nominal 1

Tabla 3.6 Valores de los atributos y valores multiplicativos asociados

El factor multiplicativo se obtiene tras la multiplicación de todos los valores anteriores. En este caso se obtiene M = 2,12 como valor multiplicativo.

PMm: Factor que se utiliza se utiliza cuando un porcentaje importante del

código se genera de forma automática. El esfuerzo requerido (PMm) se calcula de forma independiente utilizando la siguiente fórmula y después sumándola al esfuerzo calculado para el código desarrollado manualmente.

PMm = (ASLOC x (AT/100)) / ATPROD

Siendo:

ASLOC: Número de líneas de código reutilizable que deben modificarse.

AT: Porcentaje del código total del sistema que se genera automáticamente.

ATPROD: Nivel de productividad para este tipo de producción de

código.

PMm = (3 x (30/100)) / 2 = 0,45 Luego el coste laboral de este proyecto será:

P = A x ESLOCB x M + PMm = 2,5 x 1,06(1,16) x 2,12 + 0,45 = 6,12 personas-mes


- 66 -

Suponiendo que el proyecto dura 7 meses, y que el sueldo del trabajador es de 1000€/mes, obtenemos un coste de personal de:

Coste de personal = 1000 x 7 x 6,12 = 42.840€

Ahora se va a calcular el coste total del proyecto, para ello se debe añadir al coste de personal obtenido el coste material, es decir, los costes del software y del hardware, y el resto de gastos que se han estimado en el apartado anterior:

Coste Total = 42.840 + 2.650 = 45.490 €

Al coste obtenido se le añade un 10% más por si surgen imprevistos:

Coste final del proyecto = 45.490 + Contingencias 10% = 45.944,9 €

Coste final con IVA = 45.944, 9 + 16% = 53.296,1 €

CAPITULO 4 – PROCESO DE INGENIERÍA

- 67 -

4. PROCESO DE INGENIERÍA

4.1 Introducción

En el desarrollo de este proyecto se han llevado a cabo dos tareas de naturalezas bien distintas, cada una de las cuales requiere un análisis, un diseño y una implementación.

Creación de una ontología del dominio del mueble y afines, que clasifica y define los términos de la industria del mueble y afines, basándose en el estándar funStep.

Desarrollo de un interfaz que permita al usuario realizar búsquedas de

muebles en la base de conocimiento creada. En esta sección se expondrá en primer lugar todo el proceso seguido para la creación de la Ontología funStep siguiendo el ciclo de vida según la metodología METHONTOLOGY (Gomez-Pérez et al., 1996) explicada en el apartado Metodologías y librerías de ontologías del Estado del arte; y en segundo lugar, las fases de análisis y diseño de la aplicación de búsqueda.

4.2 Ontología funStep. Ciclo de vida.

La primera tarea en el desarrollo del proyecto ha sido la realización de una ontología que cubriera el ámbito del mueble y afines, incorporando modelos y definiciones del estándar internacional funStep.

Para llevar a cabo la realización de cualquier ontología, se debe tener en cuenta

la naturaleza de ésta. Siempre considerando que cualquier elemento de la ontología es un recurso o concepto y mientras se analiza y diseña no se esté haciendo otra cosa que crear conceptos. Cualquiera de estos elementos ha de servir como un recurso para cualquier otro agente semántico. Al fin y al cabo, un recurso va a acabar estando identificado por una URI, por lo tanto, un concepto será una URI que mediante la ontología será descrito.

En las secciones de este apartado se van a especificar en primer lugar los

requisitos establecidos para la creación de la ontología; y en segundo lugar, se van a exponer las distintas etapas seguidas para la definición de la ontología, que se corresponden con el ciclo de vida de creación de una ontología según la metodología METHONTOLOGY (Gómez-Pérez et al., 1996), y se detallan los pasos seguidos para llevar a cabo cada una de las etapas de esta metodología (explicadas en el apartado de Metodologías y librerías para construcción de ontologías del Estado del arte).


- 68 -

4.2.1. Especificación de Requisitos

Los requisitos establecidos para la creación de la ontología de muebles y afines son los siguientes:

El prototipo creado debe incorporar los conceptos más usados en la

industria del mueble y afines.

El prototipo debe de realizar una transcripción semántica de parte del modelo lógico funStep, mediante la creación de un prototipo conceptual, dejando de lado los modelos destinados a emplearse por bases de datos tradicionales u orientados a objetos.

El prototipo ha de ser extensible, de tal manera que sea sencillo modificar

cualquiera de sus partes e incorporar nuevas. Este requisito es fundamental, ya que en primer lugar, la ontología cubre un dominio ya establecido por la industria y funStep. Este dominio responde al acuerdo de muchas partes – fabricantes, consumidores, técnicos - , y se puede encontrar con versiones futuras que nos lleven a cambios en el modelo de datos ontológico para poder volver a cubrir todo el dominio de la aplicación. En segundo lugar, en el futuro se podría extender la ontología – vg., añadiendo propiedades o conceptos – no definidos en el modelo ontológico actual y que, por tanto, deberían añadirlos los programadores que manejen el prototipo.

El prototipo debe ser modular. De esta forma facilita la comprensión a

futuros programadores que lo manejen y de modo que una modificación en el mismo sea fácil de gestionar.

Como buena base de conocimientos, el prototipo tendrá que ser

adecuadamente documentado, para que el conocimiento, además de ser reconocido por la máquina, lo sea también para las personas.

El idioma utilizado será el inglés debido a los socios internacionales que

trabajan en funStep.

Hay que tener en cuenta que la Web Semántica es una de las áreas de conocimiento en mayor expansión, los estándares son bastante nuevos y aunque comienzan a tener amplia acogida en la actualidad, es cierto que todavía pueden cambiar de una manera considerable. Es por ello que se tendrá en cuenta la naturaleza de la solución y la selección de las herramientas para su realización.

También se tendrá en cuenta que la ontología será usada en un futuro para incluir

un volumen de datos considerable, por lo cual deberá ser compacta en cuanto a su extensión en disco.


- 69 -

4.2.2. Análisis del Modelo de Datos funStep

Uno de los requisitos enumerados anteriormente es basarse en el estándar ISO funStep para la realización de la ontología. Básicamente, se realizará una especie de transcripción semántica del modelo de datos funStep utilizado en el desarrollo de la herramienta de generación de catálogos Cadef (descrita en el segundo capítulo).

En un futuro próximo se pretende enlazar, a través de la herramienta Cadef, los productos de un catálogo funStep a los conceptos de la ontología, identificando de esta manera cada producto con el tipo de mueble que es, y en consecuencia, se le asignarían las propiedades correspondientes, a las que se podrán asignar valores. De esta manera, se conseguirá que el Cadef genere catálogos XML con las propiedades definidas en la ontología asignadas a los productos. Posteriormente, se parsearían los catálogos de XML a RDF. Y con esto, lo que se estará consiguiendo es identificar con una URI a cada elemento de nuestro catálogo, convirtiéndolo en un recurso, lo cual permitirá su localización. Y en consecuencia, la aplicación de búsqueda que se desarrolla en este proyecto podrá cargar los catálogos generados (en OWL) y acceder a ellos resolviendo las consultas de los usuarios.

La figura 4.1 muestra cómo se enlaza un producto de un catálogo en Cadef a un concepto (clase) de la ontología.

Figura 4.1 Implantación actual de la herramienta Cadef.


- 70 -

Se analizará el modelo de datos considerando en todo momento el alcance de la ontología que se va a crear, es decir, se pensará qué tipo de información se quiere almacenar en la base de conocimientos, de modo que sea posible realizar las consultas que se desea poder realizar.

El estándar ISO 10303-236 o funStep para catalogación de mobiliario y diseño de interiores, abarca el siguiente ámbito:

1) Información de datos de catalogación. 2) Representación de la forma del producto. 3) Información parametrizada de datos de catalogación. 4) Diseño interior de mobiliario.

Se pueden encontrar los detalles de cada parte en la documentación de funStep

adjuntada en el CD que acompaña esta memoria. De estas cuatro partes, nos interesa la primera y la tercera. Las otras dos se refieren a temas que no abarcará el ámbito de nuestra ontología, tales como descripción geométrica, apariencia visual del producto, etc.

A continuación se va a analizar cada una de las partes del modelo que son de nuestro interés: Catalogación. Lógicamente esta parte es la más importante puesto que en la

ontología se desea representar toda la información relacionada con los productos de un catálogo de muebles. Ver Anexo II (Data catalog.xml). Dentro de esta parte se diferenciará entre:

Organisation. Entidad que almacena toda la información sobre una

empresa y los empleados que trabajan en ella, así como la información de los productos ofrecidos por dicha empresa. Se aprovecharán las clases y los atributos que interesen para conseguir el alcance que se que se desea que tenga la ontología.

Catalog structure. Se analizan las clases que representan la información de un catálogo de muebles funStep y la representación correspondiente en la ontología.

Figura 4.2 Estructura de un catálogo de datos


- 71 -

Propiedades de producto (Ver Anexo III: Properties.xml). En el modelo funStep

existen entidades que representan dos tipos de propiedades:

Context Dependent Property (propiedad dependiente del contexto)

Context Independent Property (propiedad independiente)

De la parte del modelo de datos correspondiente a la información relacionada con la catalogación de productos se destacan las siguientes entidades:

Organisation (Organización) Product_class (Clase de producto) Product_class_relationship (Clase de relación con producto) Class_category_association (Clase de asociación de una categoría de

especificación con una clase de producto) Specification_category (Categoría de especificación) Specification (Especificación) Product_specification (Especificación de producto)

En la figura 4.4 se muestra la entidad Organisation y las clases relacionadas con ella.

Figura 4.3 Asignación de propiedades


- 72 -

Figura 4.4 Diagrama de información detallada sobre Organisation

De esta parte se trunca toda la información que tiene que ver con los empleados de una empresa, es decir, la clase Person y todas las que relacionan esta clase con Organisation. Nos quedamos con la clase Organisation (Organización) que representará en nuestro modelo a los distintos agentes de la cadena de valor (proveedores, fabricantes y comercios), y la clase Address (Dirección), que contiene toda la información de contacto de una empresa. Las entidades que representan la información de los productos de un catálogo y las relaciones entre ellas se muestran en la figura 4.5.


- 73 -

Figura 4.5 Diagrama de Product_class y sus relaciones


- 74 -

En la siguiente figura, se muestra un ejemplo representativo que ayuda a entender la información que representa cada clase.

Figura 4.6 Ejemplo de configuración detallada de un producto

El código generado en XML sería:

Observando el ejemplo anterior, nos damos cuenta de que la clase Product_class (PC) representa tanto catálogos como productos de un catálogo. Se utiliza el atributo level_type para diferenciarlos. Y Product_relationship relaciona una PC con otra. Esto en el modelo semántico, se traduciría a conceptos distintos: Catalog (Catálogo) y Product (Producto). Y de este último colgaría el concepto PieceOfFurnitture (Mueble).

Las relaciones se corresponden con las propiedades en la ontología.

La clase Specification_category (SC) representa las categorías de especificación


- 75 -

en los catálogos de mueble, tales como: materiales, colores, acabados, etc. Y la clase Specification representa valores de una SC, por ejemplo los valores: nogal, madera, rojo, etc.

A la hora de definir las propiedades de los conceptos de la ontología se analizarán dos tipos:

Propiedades generales, que serán las propiedades que tiene todo mueble en general, por ejemplo: material, color, etc.

Propiedades específicas de un tipo de mueble. Se investigarán características

específicas que tiene cada uno de los tipos de muebles.

Por último, una Product_specification es un PC con una serie de especificaciones (de color, materiales, etc.). Y esto equivale a las instancias en la representación semántica.

Tras este análisis, se obtienen las siguientes equivalencias entre las entidades del modelo de catalogación funStep y los elementos de la ontología que se quiere construir:

Modelo funStep Ontología

Product_class Conceptos (clases)

Specification_category Propiedades

Specification Valores de las propiedades

Product_specification Instancias

Tabla 4.1 Correspondencia de la Ontología con el modelo de datos

En la sección posterior de Construcción de la Ontología se verán con más detalle las decisiones tomadas para representar toda esta información en la ontología.

Otra parte que se tuvo en cuenta a la hora de transformar los elementos del modelo de datos funStep al modelo semántico formal es la de Propiedades de producto. La información contenida en esta parte permite proporcionar al usuario final el conocimiento completo sobre el producto que busca. Estas propiedades se dividen en dos grandes grupos: las propiedades dependientes del contexto y las independientes del contexto. Una propiedad dependiente del contexto sería por ejemplo el precio si se quiere tener precios diferentes para diferentes países. Otra propiedad dependiente de contexto podría ser el tamaño del producto basado en los diversos sistemas de medida, por ejemplo: pulgadas, cm., mm., etc. Una propiedad independiente del contexto debería ser un valor fijo relacionado con el producto que el propietario del catálogo quiera añadir a la información de producto. Un posible ejemplo sería tener un lema (slogan) de venta específico para cada producto.


- 76 -

Los siguientes diagramas muestran un ejemplo donde se asignan propiedades de diferentes tipos a un producto.

Figura 4.7 Ejemplo de propiedad dependiente de contexto

Figura 4.8 Ejemplo de propiedad independiente del contexto


- 77 -

Todas las características que nos interesen sobre un producto se traducirán en la ontología a propiedades que pueden ser de dos tipos: propiedades objeto (ObjectProperty) o propiedades de tipos de datos (DatatypeProperty), lo cual determinará el rango de valores que pueden tomar. En el apartado de Construcción de la Ontología se verán las decisiones tomadas para representar los distintos tipos de propiedades. 4.2.3. Adquisición de Conocimientos

Como se vio en el apartado Metodologías y librerías de ontologías del Estado del arte, la fase de “Adquisición de conocimientos” se realiza durante todo el ciclo de vida de la ontología.

A continuación, se describen las principales fuentes de información que fueron

consideradas para adquirir conocimiento en el dominio que cubrirá nuestra ontología:

1) Normas de mobiliario: ISO funStep: ISO 10303-236 “Sistemas de automatización industrial e

integración – representación e intercambio de los datos de Producto – Parte 236: Protocolo de aplicación: Catálogo de muebles y diseño de interiores”.

UNE-EN 1129-1:1995 MOBILIARIO. CAMAS ABATIBLES. REQUISITOS DE SEGURIDAD Y ENSAYOS. PARTE 1: REQUISITOS DE SEGURIDAD.

UNE-EN 1130-1:1996 MUEBLES. MOISÉS Y CUNAS BALANCÍN DE USO DOMÉSTICO. PARTE 1: REQUISITOS DE SEGURIDAD.

UNE-EN 13150:2001 MESAS DE LABORATORIO. DIMENSIONES, REQUISITOS DE SEGURIDAD Y MÉTODOS DE ENSAYO.

UNE-EN 1727:1998 MOBILIARIO DOMÉSTICO. MUEBLES CONTENEDORES. REQUISITOS DE SEGURIDAD Y MÉTODOS DE ENSAYO.

UNE-EN 1728:2001 MOBILIARIO DOMÉSTICO. ASIENTOS. MÉTODOS DE ENSAYO PARA LA DETERMINACIÓN DE LA RESISTENCIA Y DE LA DURABILIDAD.

UNE-EN 1730:2000 MOBILIARIO DOMÉSTICO. MESAS. MÉTODOS DE ENSAYO PARA LA DETERMINACIÓN DE LA RESISTENCIA, LA DURABILIDAD Y LA ESTABILIDAD

UNE-EN 581-1:1998 MOBILIARIO DE EXTERIORES. ASIENTOS Y MESAS DE USO DOMÉSTICO, PÚBLICO Y DE CAMPING. PARTE 1: REQUISITOS GENERALES DE SEGURIDAD.


- 78 -

UNE-EN 716-1:1996 MUEBLES. CUNAS Y CUNAS PLEGABLES DE USO DOMÉSTICO PARA NIÑOS. PARTE 1: REQUISITOS DE SEGURIDAD.

UNE-EN 747-1:1994 MOBILIARIO. LITERAS PARA USO DOMESTICO. PARTE 1: REQUISITOS DE SEGURIDAD. (VERSION OFICIAL EN 747-1:1993).

UNE-ENV 1178-1:1996 MOBILIARIO. SILLAS ALTAS DE USO DOMÉSTICO PARA NIÑOS. PARTE 1: REQUISITOS DE SEGURIDAD. (ISO 9221-1, MODIFICADA).

UNE-ENV 12520:2000 MOBILIARIO DOMÉSTICO. ASIENTOS. REQUISITOS MECÁNICOS Y ESTRUCTURALES DE SEGURIDAD.

UNE-ENV 1729-1:2002 MOBILIARIO. SILLAS Y MESAS PARA CENTROS DE ENSEÑANZA. PARTE 1: DIMENSIONES FUNCIONALES.

UNE-ENV 581-2:2000 MOBILIARIO DE EXTERIOR. ASIENTOS Y MESAS DE USO DOMÉSTICO, PÚBLICO Y DE CAMPING. PARTE 2: REQUISITOS DE SEGURIDAD MECÁNICA Y MÉTODOS DE ENSAYO PARA ASIENTOS.

2) Entrevistas con expertos en el sector. Se han mantenido entrevistas y reuniones con personas expertas en el sector, dentro de la empresa (p.ej. personal de los laboratorios y personal del Departamento de I+D).

3) Catálogos de muebles (técnicos y de comerciales). Se han consultado catálogos de diferentes sectores de mobiliario: Oficinas (ej.: Catálogo de mobiliario de oficina de Federico Giner) Infantil y juvenil (ej.: Líneas Taller de Muebles) Sofás (ej.: Tapigroup, Capdell, Koo International) Cocinas (ej.: Block Cocinas) Más.

4) Diccionarios y enciclopedias:

Diccionario de la RAE María Moliner Webster (última edición) Collins English Dictionary & Thesaurus The Encyclopedia of Furniture: Third Edition - Completely Revised Wikipedia

Considerando el tema de la integración de otras ontologías, comentado en el

apartado de Metodologías y librerías de ontologías del Estado del arte, se investigaron ontologías relacionadas con muebles y afines, pero solamente se encontraron taxonomías de alcance muy limitado (sillas de oficina, p.ej.). Con lo cual, se analizarán


- 79 -

dichas taxonomías, identificando cada uno de los conceptos clasificados y descubriendo el proceso de construcción de las mismas. Y posteriormente, se ampliarán con nuevos conceptos (términos de muebles, sus componentes y algunos accesorios) para conseguir cubrir el dominio de nuestra ontología.

Los diferentes tipos de muebles han sido clasificados atendiendo al criterio del tipo de mueble (ej. mesa, silla, cama, etc.), y al criterio de uso o destino del mueble (ej. mesa de cocina, silla de comedor, cama de hospital, etc.).

4.2.4. Especificación de la Ontología

La Especificación es la primera actividad en el desarrollo de una ontología. Es la fase donde se identifican el objetivo y el alcance de la misma.

En este caso, el objetivo a conseguir es una ontología que defina formalmente

los conceptos de los distintos tipos de muebles disponibles en el mercado y sus componentes, así como accesorios, y que contenga información relevante relacionada con el sector mobiliario.

Para determinar el alcance se va a tratar de responder a una serie de preguntas

básicas:

¿Para qué se usará la ontología? ¿Para qué tipos de preguntas la información en la ontología deberá proveer

respuestas? ¿Quién usará y mantendrá la ontología?

Las respuestas a estas preguntas pueden cambiar durante el proceso de diseño de

la ontología, pero en cualquier momento ayudarán a limitar el alcance del modelo. La ontología construida será usada principalmente para realizar búsquedas de

muebles basadas en una serie de especificaciones indicadas por el usuario, y poder consultar información relacionada con el mueble buscado. Por lo tanto, será un servicio enfocado hacia el cliente final y también hacia el comercio.

Servirá también, combinada con las herramientas de anotación semántica

desarrolladas en el proyecto europeo ATHENA (Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications), para anotar semánticamente imágenes, dibujos y diseños de muebles, ya procedan de catálogos de fabricantes o distribuidores o de recursos de la web.

En nuestra ontología figurarán conceptos que describen diferentes tipos de

muebles y sus principales componentes, algunos tipos de complementos (lámpara, escalera, etc.), nociones que representen las características de un mueble que puedan interesar al cliente, tales como precio, material, estilo, fabricante o dimensiones de un mueble.

A continuación se listan los tipos de consultas que se desean realizar sobre la

ontología:


- 80 -

Búsqueda de un mueble por: Fabricante Tipo de mueble Estilo Distribuidor (geográficamente)/quién y dónde encontrarlo Material Color Tamaño Estilo Precio. Búsqueda por rango de precio Dimensiones (Alto, Ancho, Profundo)

¿Cuál es el precio de un mueble?

Buscar una composición por tipos de muebles que la componen

Una vez especificado el dominio de la ontología y limitado el alcance de la misma, se debe pensar en los términos y las propiedades relacionados con el dominio de interés. Por ejemplo, términos importantes relativos a los muebles incluirán: composición, fabricante, material, color, estilo, precio, etc. Inicialmente es importante obtener una lista integral de términos sin preocuparse del recubrimiento entre los conceptos que representan, relaciones entre los términos, o cualquier propiedad que los conceptos puedan tener, o si los conceptos son clases o slots. 4.2.5. Decisiones de diseño

Antes de pasar a describir el proceso de construcción de la ontología, se comentarán en este apartado las decisiones tomadas y sus argumentaciones, al igual que algunos aspectos que se tuvieron en cuenta en la especificación de la ontología. Como ya se ha explicado en la parte de metodologías del estado del arte, no existe una simple y correcta metodología de diseño de ontologías. Para el desarrollo de nuestra ontología nos hemos basado en una guía para definición de ontologías propuesta por Natalya F. Noy and Deborah L. McGuinness.

La primera decisión que se tuvo que tomar para el desarrollo de la ontología fue

el lenguaje de marcado para expresarla. Se optó por el lenguaje OWL frente a RDFS ya que es mucho más expresivo, además de que facilita la importación y exportación de clases: incluye propiedades como sameAs, equivalentClass, equivalentProperty, differentFrom, etc. La propiedad equivalentClass por ejemplo, permite expresar que dos clases de ontologías distintas son equivalentes, lo que significa que cada instancia de una clase será también instancia de la otra, y viceversa. La capacidad de expresar que dos entidades son iguales resulta muy útil cuando se integran o se mezclan ontologías, y permite la interoperabilidad.

Dentro del lenguaje OWL, tenemos que decidir entre los tres sublenguajes: OWL-

Lite, OWL-DL y OWL-Full. Se descarta desde un principio OWL-Lite ya que es la versión más incompleta, solo permite la jerarquía simple y restricciones simples.


- 81 -

Tampoco permite las restricciones de tipo “hasValue”, ni clases disjuntas, etc.Y solamente admite cardinalidad 0 o 1. Esto no cubre nuestras necesidades, pues no se podría expresar que una mesa tiene cuatro patas por ejemplo.

Para decidir entre OWL-DL y OWL-Full se realizó un estudio comparativo que

ayudara a tomar una decisión. Por múltiples motivos, se decidió que fuera OWL-DL: Es decidible. Se puede analizar en toda su extensión por una máquina.

En OWL-DL no se puede decir que una clase es clase e instancia a la vez.

Es muy expresivo Cubre la expresividad que necesitamos.

Existen razonadores que lo utilizan, no habrá problemas para utilizar cualquier razonador sobre una ontología definida de esta manera.

Es el estándar en ontologías que se ha establecido y está auspiciado por la W3C.

Recordemos que la ontología será creada teniendo en cuenta el modelo de datos del estándar ISO funStep. En la sección de Análisis del modelo de datos funStep, se realizó un estudio del esquema conceptual, destacando aquellas partes que nos interesan. Veamos ahora cómo se tradujeron los diferentes elementos de interés del esquema conceptual a modelo semántico formal:

La entidades del modelo de datos se transforman en clases y/o individuales según criterio y establecimiento de su jerarquía.

Hay dos formas de representar los elementos de una clase, como

individuales o como subclases [Cec02]. El uso de clases es semánticamente más rico y hace que la ontología se pueda extender más fácilmente.

Los atributos de algunas entidades se transformarán en propiedades. Pasos a

seguir:

a) Estas propiedades podrán ser de dos tipos: propiedades objeto (ObjectProperty) o propiedades de tipos de datos (DatatypeProperty), lo cual determinará el rango de valores que pueden tomar.

i. Propiedades objeto son usadas para relacionar un recurso a

otro recurso. ii. Propiedades de tipos de datos únicamente relacionan un

recurso a un rdfs:literal o a un tipo de datos perteneciente a XML Schema.

b) Se estudiará según criterios dados la conveniencia de restringir

estas propiedades globalmente: Rango y Dominio.


- 82 -

i. Más tarde en el proceso, será posible restringir el rango especificado en una propiedad de una clase padre, cuando dicha propiedad afecta a clases descendientes, siempre y cuando ese nuevo conjunto de valores que la propiedad pueda tomar sea un subconjunto del rango de valores original de la clase ascendente. Esto se logrará mediante operadores de cuantificación generalmente.

c) Definición de características de las propiedades: Transitivas,

Inversas, Simétricas.

i. Hay que tener en cuenta que las características de transitividad o simétría solo podrán ser aplicadas en propiedades de tipo objeto (relacionan dos recursos).

d) Inclusión de dicha propiedad en una jerarquía de propiedades

(elección de superpropiedad(es)) que ayudará en la aplicación de posibles métodos de inferencia.

Atendiendo al alcance de nuestra ontología, las entidades del modelo de datos que necesitamos mapear son las siguientes: Organisation (Organización). Queremos tener información sobre el fabricante de

un mueble y el comercio donde lo podemos encontrar. Para ello se decidió crear una clase abstracta “Organización”, que tendrá como subclases los conceptos de “Fabricante”, “Comercio” y “Proveedor”.

Address (Dirección). Nos interesa conocer información de contacto de un

comercio para localizar un determinado mueble. Esta entidad se mapeará como una clase en la ontología y todos sus atributos como propiedades de dicha clase.

Product_class (Clase de prodcuto). Como vimos en el apartado de análisis del

modelo de datos funStep, esta clase representa tanto un catálogo como un producto. Por lo tanto, en la ontología crearemos dos conceptos nuevos: Catálogo y Producto, y la relación entre ellos (“Catalog hasProduct Product”) será una propiedad de tipo no funcional, es decir, que un catálogo tiene varios productos.

En cuanto a la parte “Propiedades de producto” se representará mediante propiedades asignadas a la clase “Producto”. Vimos en el análisis del modelo que en funStep existen dos tipos de propiedades de producto: las dependientes del contexto y las independientes del contexto. Estas propiedades serán representadas en la ontología mediante dos tipos de propiedades respectivamente: propiedades objeto (ObjectProperty) y propiedades de tipo de dato (DatatypeProperty). Para la información de localización de una empresa (comercio o fabricante de muebles) se consideraron dos cosas:

La reutilización de ontologías ya existentes que definan los conceptos correspondientes a los atributos de la clase Address. Esta solución no fue


- 83 -

llevada a cabo por dos motivos: No se ha encontrado una ontología que defina un dominio que cubra todos los atributos que tenemos en Address. Y porque nuestro dominio está muy bien definido y queríamos que tuviera todas las clases necesarias.

La creación de una ontología que defina el subdominio de Dirección.

Esta opción también fue ignorada al final, ya que se consideró que no merece la pena

En el siguiente diagrama se representan los distintos elementos que acabo de comentar y cómo se relacionan entre ellos en la ontología:

Figura 4.9 Esquema de los conceptos mapeados a la ontología Las clases generadas a partir del modelo de datos son aquellas que permitirán almacenar la información que se quiere obtener sobre los mueble. El resto de las clases de la ontologia serán las corresponsientes a términos de muebles, componentes de muebles y algunos accesorios. En el apartado de Construcción de la ontología se verán un poco los detalles sobre cómo se han ido desarrollando los distintos pasos de creación de la ontología, y algunas decisiones tomadas.


- 84 -

4.2.6. Construcción de la Ontología

En este apartado se van a exponer los pasos seguidos para la construcción de la ontología (Noy y McGuinness, 2005).

Para construir la ontología se eligió como plataforma de desarrollo el editor Protégé por una serie de razones:

1) Ofrece un entorno amigable para la realización de ontologías y una gran cantidad de documentación que ayuda al aprendizaje de la herramienta como a la utilización de la misma durante la implementación.

2) Es el más expandido. Se actualiza a menudo.

3) Permite integrar funcionalidades fácilmente mediante plugins. Se utilizó más concretamente el plugin Protégé-OWL (Matthew Horridge et al., 2004) que viene instalado por defecto en el programa. Este plugin ofrece muchas singularidades para la generación de ontologías con el lenguaje de marcado OWL. El programa y el plugin están desarrollados y mantenidos por la Universidad de Stanford y son de libre distribución. Pasemos ahora a detallar los pasos correspondientes a la creación de la ontología que se enumeraron en el apartado de Metodologías y librerías de ontologías del Estado del arte.

1) Definir las clases y la jerarquía de clases La taxonomía de muebles construida clasifica a éstos atendiendo al criterio del tipo de mueble en primer lugar, y en segundo lugar al criterio de uso del mueble o destino, de modo que se tienen los niveles que se muestran en la captura de Protégé de la figura 4.9. El nivel superior (top level) está formado por los conceptos más generales como: Mueble (Piece of furniture), Cama (Bed), Mueble infantil (Children piece of furniture), Puerta (Door), Pantalla (Screen), Asiento (Seat), Mueble de almacenaje (Storage piece of furniture) y Mesa (Table). Y las clases de nivel inferior en la jerarquía (bottom level) son las más específicas, como: Mesa de comedor (Dining Table), Mesita de noche (Bedside Table), Mesa de cocina (Kitchen Table), etc.

Se ha conseguido establecer una taxonomía bastante detallada, que clasifica básicamente todos los tipos de muebles existentes actualmente en el mercado. En la figura 4.9 se pueden ver los dos primeros niveles de la jerarquía (para ver la taxonomía completa dirigirse al archivo FurnitureOntology.owl que se encuentra en el CD que acompaña esta memoria).


- 85 -

Figura 4.10 Diferentes niveles de la taxonomía de muebles


- 86 -

Obtenida la taxonomía de muebles, hubo que detallar los conceptos de los elementos que componen los diferentes tipos de muebles (por lo menos los más generales). Para ello, se han tenido que tomar ciertas decisiones de diseño. Es fundamental obtener una buena clasificación de estos términos puesto que posteriormente, la definición de los conceptos de muebles se hará a partir de su composición. La siguiente figura muestra una captura de Protégé con la jerarquía de conceptos de componentes de muebles que se han definido:

Figura 4.11 Jerarquía de Componentes de muebles

2) Definir las propiedades de las clases

Las clases definidas en la taxonomía de muebles son clases aisladas, es decir, se corresponden con términos de objetos que tienen existencia independiente. Estas clases no proveen suficiente información para responder a las preguntas de competencia que determinan el alcance de nuestra ontología (expuestas en el apartado anterior de Especificación de la Ontología). Se necesita definir términos que describan la estructura interna de los conceptos. Estos términos serán clases que se relacionan con las clases definidas anteriormente, a través de propiedades de tipo Objeto. A parte de las propiedades de tipo Objeto, existen otro tipo de propiedades: Datatype (propiedades de tipo de dato). A continuación se muestran ejemplos de cada tipo.


- 87 -

Propiedades de tipo Objeto. Tal como muestra el ejemplo de la figura 4.11, PieceOfFurniture tiene

propiedades que la vinculan con Material, Style, Use, Finish, etc. Además de estas propiedades generales de un mueble, tenemos las propiedades de tipo Objeto que relacionan un mueble de tipo concreto con sus componentes (las clases que se muestran en la figura 4.11.). De manera que tendremos propiedades como hasArmrest (tiene_reposabrazos), hasBackrest (tiene_ respaldo) o hasSeatPart (tiene_asiento) para la clase Chair (Silla); y propiedades como hasHeadboard (tiene_cabecero) o hasMattress (tiene_colchón) para Bed (Cama).

Por convenio, el nombre de las propiedades comienza por “has”.

Figura 4.12 Propiedades de PieceOfFurniture. Resaltada hasMaterial

Para cada propiedad se define un Rango y un Dominio determinados. Ver figura 4.12. El Rango indica los valores que puede tomar la propiedad, y el Dominio, son las clases a las que se asigna dicha propiedad. Existen unas reglas básicas que se han seguido para definir ambos:

Cuando se define un dominio o rango de una propiedad, se debe encontrar las clases o clase más generales que puedan ser respectivamente el dominio o rango de las propiedades. Por otro lado, no definir un dominio ni rango que sea demasiado general: todas las clases en el dominio de una propiedad deben ser descritas por la propiedad y las instancias de todas las clases en el rango de una propiedad deben poder ser rellenos potenciales de la propiedad. No elegir una clase demasiado general para el rango (por ej., es inútil crear un rango COSA (THING)) pero es posible elegir una clase que cubre todos los valores de relleno. (Noy y McGuinness, 2005)


- 88 -

Una propiedad de tipo Objeto en OWL puede ser (MathewHorridge et al., 2004):

Funcional. Esto se refiere a la cardinalidad de la propiedad. Una propiedad es funcional (functional) si para una instancia determinada, permite tener sólo un único valor (una única instancia) del rango definido.

Inversamente funcional. Si una propiedad es “inversamente funcional” significa que la propiedad inversa1es funcional.

Transitiva. Si una propiedad es transitiva y la propiedad relaciona una

instancia a con otra b, y también la instancia b con c, entonces se puede inferir que a se relaciona con c a través de la propiedad.

Simetría. Si una propiedad P es simétrica, y relaciona la instancia a con

b, significa que b también se relaciona con a a través de la propiedad P.

Figura 4.13 Detalles de la propiedad hasMaterial

1 En OWL, toda propiedad de tipo objeto tiene su correspondiente propiedad inversa. Si una propiedad enlaza la instancia a con b, la propiedad inversa es la que enlaza la instancia b con a.


- 89 -

Propiedades de tipos de dato. Datatype Properties. Ver Figura 4.13.

Estas son propiedades cuyo rango es un valor fijo o literal. Una de las

características que hacen potente a OWL es la capacidad para trabajar con tipos definidos.

Para este tipo de propiedades se puede establecer una lista de valores permitidos (allowed values). En OWL, esto se implementa mediante la propiedad oneOf como podemos ver en el siguiente trozo de código que muestra un ejemplo de la definición de la propiedad hasUnit, que especifica la unidad2 en la que se expresa el precio de un producto.

<owl:FunctionalProperty rdf:ID="hasUnit"> <rdfs:range> <owl:DataRange> <owl:oneOf rdf:parseType="Resource"> <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Points</rdf:first> <rdf:rest rdf:parseType="Resource"> <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >€</rdf:first> <rdf:rest rdf:parseType="Resource"> <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >$</rdf:first> <rdf:rest rdf:resource="http://www.w3.org/1999/02/22‐rdf‐syntax‐s#nil"> </rdf:rest> </rdf:rest> </owl:oneOf> </owl:DataRange> </rdfs:range> <rdfs:domain rdf:resource="#Price"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> </owl:FunctionalProperty>

2 En los catálogos de los fabricantes, los precios de los productos se indican en “puntos”. Luego cada comercio establece un valor para el punto.


- 90 -

Figura 4.14 Propiedad de tipo Datatype

3) Establecer Restricciones a las propiedades Las restricciones se definen para restringir los individuos que pertenecen a una clase. Existen tres categorías principales:

Restricciones de “cuantificador” (“quantifier restrictions”) Los cuantificadores usados son:

El cuantificador existencial (Ǝ), que se puede leer como al menos un, o algún3. Por ejemplo, la restricción “Ǝ hasBase BedBase” establecida para la clase Bed, indica que toda instancia de Cama debe tener al menos una base de cama (BedBase). Pero esta restricción sola, no significa que la propiedad hasBase no pueda tomar valores de otro tipo de base, como por ejemplo Pedestal. Por eso, necesitamos establecer otro axioma que restrinja eso.

El cuantificador universal (), que se puede leer como sólo

3 En OWL se expresa como restricción “someValuesFrom”


- 91 -

(only4). Siguiendo con el ejemplo de antes, la restricción “ hasBase BedBase” indica que una instancia de Cama se puede relacionar a través de la propiedad hasBase sólo con instancias de la clase BedBase. Esta restricción por sí sola no expresa que la clase Cama tenga una base necesariamente, es decir, la propiedad hasBase puede no existir, y en caso de que exista entonces sólo podrá tomar valor de los tipos indicados. Son los llamados axiomas de clausura y son necesarios desde el punto de vista de Open World Assumtion. Esta asunción del mundo abierto se explica en el apartado de Bases de conocimiento frente a Bases de d del Estado del arte.

Restricciones de cardinalidad (cardinality restrictions)

En estas restricciones se establece la cantidad de elementos que pueden relacionarse a través de la propiedad. No son locales a la propiedad, es decir, si una misma propiedad tiene dos dominios distintos, puede tener restricciones distintas para cada dominio. Esta es una de las grandes diferencias que hay entre RDF Schema y OWL.

Figura 4.15 Restricciones de las propiedades de Chair

Veamos un trozo del código generado por Protégé que muestra un ejemplo de restricciones para la clase Stool (taburete), que es subclase de Seat (asiento), pero por ser una clase bien definida (tiene restricciones que son “necesarias y suficientes”), el código generado no es muy intuitivo, pues no se utiliza la propiedad subclassOf de RDF Schema (para definirla como subclase de Seat), sino la propiedad “equivalentClass” de OWL. Si analizamos el código, vemos que Stool es equivalente a Seat con unas

4 En OWL se expresa como restricción “allValuesFrom”


- 92 -

restricciones de las propiedades hasBase y hasSeat. La restricción de hasBase establece los valores que puede tomar esta propiedad de la clase Base. Y la restricción de hasSeat es de cardinalidad, indica que la cardinalidad de hasSeat es 1 para la clase Stool. Hay que tener mucho cuidado a la hora de definir restricciones necesarias y suficientes, pues implica una equivalencia en ambos sentidos, es decir, que sea Stool por ejemplo, implica por una parte que debe cumplir todas las restricciones definidas, y por otra parte, que cualquier cosa que cumpla dichas restricciones, será un Stool.

<owl:Class rdf:ID="Stool"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty rdf:resource="#hasBase"/> <owl:allValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#CantileverFrame"/> <owl:Class rdf:about="#Leg"/> <owl:Class rdf:about="#Pedestal"/> </owl:unionOf> </owl:Class> </owl:allValuesFrom> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#hasSeat"/> <owl:cardinality rdf:datatype="&xsd;int">1</owl:cardinality> </owl:Restriction> <owl:Class rdf:about="#Seat"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <owl:disjointWith rdf:resource="#Bench"/> <owl:disjointWith rdf:resource="#Chair"/> <owl:disjointWith rdf:resource="#Swing"/> <owl:disjointWith rdf:resource="#Sofa"/> </owl:Class>

Restricciones “hasValue” Estas restricciones asignan un valor determinado a la propiedad. En la figura 4.15 se puede ver un ejemplo de este tipo de restricción para la clase Sofa, donde se le da el valor UpholsteredHomeUse (uso de tapizados de hogar) a la propiedad hasUse.


- 93 -

Figura 4.16 Restricción de tipo hasValue para la clase Sofa

4) Crear instancias El último paso consiste en crear instancias individuales de clases en la jerarquía. La definición de una instancia individual de una clase requiere (1) elegir una clase, (2) crear una instancia individual de la clase y (3) rellenar los valores de las propiedades. En este paso se han creado en primer lugar las instancias de aquellas clases denominadas clases de instancias, es decir, toda clase creada para ser Rango de una determinada propiedad. Por ejemplo las clases: Material, Finish, Style, etc. De esta manera obtenemos la versión de la ontología sin instancias de muebles. Posteriormente, se crean las instancias de muebles, extraídas de catálogos de fabricantes, obteniendo así una base de conocimiento de prueba, sobre la cual se realizarán consultas con el buscador.


- 94 -

4.3 Aplicación de Búsqueda Web

El segundo objetivo principal a conseguir en este proyecto es el desarrollo de

una aplicación web para realizar búsquedas dirigidas al sector mobiliario. Esta aplicación debe ser capaz de permitir a los usuarios realizar consultas complejas y obtener resultados exactos, proporcionándoles un interfaz gráfico amigable, sencillo y rápido.

El sistema accederá a la base de conocimiento creada en la primera parte de este

proyecto. Esta base de conocimiento está constituida por la Ontología funStep de muebles y afines con los conceptos y relaciones definidos, más las instancias de muebles introducidas. Más adelante, en el apartado de Implementación, se verá cómo se implanta la ontología en la aplicación web y las herramientas utilizadas para acceder a la información de la base de conocimiento cargada.

En este apartado se van a exponer las fases de análisis y diseño del sistema

desarrollado.

4.3.1. FASE DE ANÁLISIS En esta fase se van a especificar los requisitos establecidos para la realización del prototipo y se va a analizar el sistema a desarrollar.

La especificación de requisitos del sistema es una tarea muy importante en cualquier proyecto software, pues de ella dependerá que el producto final sea del agrado del cliente. Una mala especificación de requisitos puede llevar a serios problemas en el calendario de trabajo ya que se tendrían que modificar aquellas partes del sistema que no se especificaron correctamente para adecuarlas a los requisitos reales.

Conforme se avanza en el proyecto se hace más costoso realizar algún cambio en

los requisitos, por ejemplo, si se produce en la fase de implementación se hace muy costoso ya que habría que modificar la especificación de requisitos, el análisis, el diseño y la implementación tanto del módulo afectado como de los módulos que se comunican con él. Sin embargo, si se produce en la fase de especificación de requisitos su coste es ínfimo.

Con una buena especificación de requisitos se proporcionará una visión global y

a la vez específica del sistema a desarrollar, que será coherente con los requisitos establecidos por el cliente y servirá como base para el diseño e implementación del sistema.


- 95 -

4.3.1.1.Especificación de requisitos El sistema a desarrollar es una aplicación que permita a los usuarios realizar búsquedas específicas de productos de la industria del mueble. El usuario deberá poder describir las características del mueble que busca a través de un interfaz sencillo y amigable, y el sistema deberá permitir al usuario obtener información sobre los productos disponibles en los catálogos de diferentes comercios y/o fabricantes. El buscador desarrollado estará basado en tecnología semántica y por ello, permitirá realizar consultas inteligentes y estructuradas a diferencia de un buscador convencional que se basa simplemente en la concordancia de una serie de palabras clave.

El sistema accederá a la información almacenada en la base de conocimiento creada previamente. Los requisitos establecidos para el desarrollo de este sistema son los siguientes: El prototipo creado ha de ser accesible vía web para que el usuario pueda hacer

uso de la aplicación de búsqueda de la manera más fácil y cómoda posible, a través de un navegador web.

El buscador desarrollado ha de hacer uso de un vocabulario común (funStep), es decir, de los conceptos y relaciones definidas en la ontología del dominio del mueble y afines que hemos creado previamente.

El buscador debe estar enfocado hacia el cliente, que puede ser un comercio, o bien, el cliente final. En general, el tipo de búsquedas que se desea poder realizar son: buscar un mueble con unas características determinadas, muebles de un determinado fabricante, o bien los muebles que vende un determinado comercio. El hecho de que el usuario pueda ser un cliente final quiere decir que, probablemente no tenga ningún conocimiento sobre el sector del mueble, y por ello, se desea poder hacer uso de un lenguaje sencillo y común a la hora de especificar las características deseadas en el mueble buscado.

El prototipo tiene que permitir al usuario realizar como mínimo una serie de consultas que se corresponden con las preguntas de competencia establecidas a la hora de crear la ontología:

Buscar un mueble por:

Tipo: mesa, silla, armario, cama, etc.

Uso del mueble: de cocina, de comedor, de casa, de

colectividades, etc.

Estilo: moderno, clásico, vanguardista, etc.

Material: madera, metal, plástico o cristal.


- 96 -

Acabado: tapizado, barnizado, pintado, chapado, etc.

Color

Dimensiones del mueble (ancho, alto y profundo)

Rangos de precio

Fabricante

Localidad del comercio o punto de venta que lo vende. El sistema debe ser de fácil uso, intuitivo para el usuario. Los resultados de la petición deben obtenerse en poco tiempo.


- 97 -

4.3.1.2.Funcionalidades del sistema

Para definir las funcionalidades del sistema es necesario saber quién va a utilizarlo. Teniendo en cuenta el tercer requisito establecido, se identifica un único tipo de actor que interactúa con el sistema: cualquier usuario que accede a la aplicación para realizar búsquedas de información relacionada con el sector del mueble y afines. Podrá ser un cliente final o bien un comercio, pero la funcionalidad de la aplicación será la misma para ambos. Sabiendo quién va a utilizar el sistema, se puede pasar a definir las funcionalidades que va a tener éste:

Ref. Función Categoría

F1.1 Introducir características deseadas. Evidente

F1.2 Realizar búsqueda. Evidente

F1.3 Buscar mueble o composición (producto) por fabricante. Oculta

F1.4 Buscar producto por comercio. Oculta

F1.5 Buscar producto por rangos de precios. Oculta

F1.6 Buscar producto por acabado Oculta

F1.7 Buscar producto por color. Oculta

F1.8 Buscar mueble por tipo. Oculta

F1.9 Buscar mueble por uso. Oculta

F1.10 Buscar mueble por material. Oculta

F1.11 Buscar mueble por estilo. Oculta

F1.12 Buscar mueble por dimensiones. Oculta

F1.13 Buscar composición por ambiente o destino. Oculta

F1.15 Buscar composición por tipo de muebles que la componen. Oculta

F1.16 Obtener detalles de un producto Evidente

F1.17 Mostrar información sobre el producto seleccionado. Oculta

Tabla 4.2.- Funciones del Sistema


- 98 -

4.3.1.3.Casos de uso Una vez determinados los requisitos que debe cumplir el sistema, identificados los actores y las funciones del mismo, se procede a representar los casos de uso. El interfaz diseñado deberá permitir al usuario introducir una serie de características, que serán recogidas por la aplicación para formular la consulta correspondiente y devolver los resultados obtenidos. A continuación, se muestran los diagramas de casos de uso del sistema:

Figura 4.17 Diagrama de Casos de Uso.

Los casos de uso “Buscar Muebles” y “Buscar Composiciones” son muy genéricos, por lo que se van a detallar a continuación:


- 99 -

Figura 4.18 Caso de uso Buscar Muebles detallado.

Figura 4.19Caso de uso Buscar Composiciones detallado.


- 100 -

El establecimiento de los casos de uso permite definir el sistema desde el punto de vista funcional, antes de abordar su estructura interna. A continuación se van a exponer de forma detallada cada uno de los casos de uso principales del sistema: Caso de uso: Especificar tipo de mueble buscado Actores: Usuario

Propósito: Indicar el tipo de mueble que se desea buscar (mueble o composición).

Tipo: Principal Descripción: El usuario especifica el tipo de mueble que busca. El sistema

muestra el interfaz correspondiente al tipo de mueble especificado.

Referencias: F1.1 Secuencia típica de eventos: Actor Sistema 1.- El usuario accede a la aplicación y desea buscar un producto.

2.- El usuario selecciona el tipo de producto que desea buscar.

3.- Muestra el interfaz con las propiedades correspondientes al tipo de producto elegido por el usuario.

Caso de uso: Realizar una búsqueda Actores: Usuario Propósito: Solicitar la búsqueda de un producto (mueble o composición) con

unas características especificadas. Tipo: Principal Descripción: El usuario pulsa el botón de búsqueda tras indicar las

características del producto buscado. El sistema devolverá una lista de instancias que cumplan con las características especificadas por el usuario.

Referencias: F1.2, F1.3, F1.5, F1.6, F1.7, F1.8, F1.9, F1.10, F1.11, F1. 12,

F1.13, F1.14, F1.15


- 101 -

Secuencia típica de eventos: Actor Sistema 1.- El usuario selecciona las características que desea en el producto que busca.

2.- El usuario pulsa el botón de búsqueda tras indicar las características buscadas.

3.- Recoge del interfaz los valores indicados de las propiedades.

4.- Genera y ejecuta la consulta correspondiente.

5.- Devuelve una lista con las instancias resultado de la consulta.

Caso de uso: Obtener detalles de un producto Actores: Usuario Propósito: Obtener información detallada sobre un producto específico. Tipo: Principal Descripción: El usuario selecciona un producto de la lista devuelta por el

sistema resultado de la búsqueda solicitando obtener información detallada sobre un producto específico. El sistema realiza las consultas necesarias y muestra al usuario una serie de detalles sobre el producto seleccionado, tales como descripción, fabricante, materiales, acabados y colores disponibles, etc.

Referencias: F1.16, F1.17. Secuencia típica de eventos: Actor Sistema 1.- El usuario selecciona un producto de la lista para obtener detalles.

2.- Genera y ejecuta la consulta correspondiente.

3.-Muestra la información del producto en el interfaz de usuario.


- 102 -

4.3.1.4.Diagramas de Actividad Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un caso de uso, así como las distintas rutas que pueden irse desencadenando en el caso de uso. A continuación se muestran los diagramas de actividad de nuestro sistema:

Figura 4.20 Diagrama de Actividad – Especificar tipo mueble


- 103 -

Figura 4.21 Diagrama de Actividad – Realizar Búsqueda


- 104 -

Figura 4.22 Diagrama de Actividad – Obtener detalles


- 105 -

4.3.1.5.Análisis del interfaz de usuario

Una vez establecidos los requisitos del sistema e identificados los casos de uso, se pueden analizar los componentes que va a tener el interfaz de usuario.

El interfaz debe proporcionar vistas para que el usuario pueda realizar lo

siguiente:

1) Elegir tipo de producto a buscar entre la variedad de productos definidos en la ontología. Se proporcionará una estructura de árbol con la jerarquía de productos disponibles.

2) Buscar un producto genérico. El usuario tendrá la elección de realizar una búsqueda muy detallada o bien búsquedas más genéricas. Por ejemplo, puede que no indique un tipo específico de mueble, y quiera obtener la lista de todos los productos de un comercio en concreto. Por ello, se proporcionará una pantalla con propiedades genéricas y con el botón de buscar.

3) Buscar un tipo de mueble específico. El usuario podrá elegir un tipo de mueble específico entre los diferentes tipos que existen. La jerarquía de clasificación de muebles de la ontología es demasiado extensa y detallada, se proporcionará una pantalla para los tipos de mueble definidos en el primer nivel de la jerarquía. Según el tipo de mueble elegido por el usuario se mostrará una pantalla u otra con las propiedades específicas de cada tipo. Habrá cuatro pantallas distintas para:

Búsqueda de una Mesa (mesitas, mesas de comedor, escritorios, etc.) Búsqueda de un Asiento (sillas, sillones, sofás, sillas de ruedas, etc.) Búsqueda de un Mueble de almacenaje (armarios, vitrinas, cómodas, etc.) Búsqueda de una Cama (individual, doble, de hospital, camillas, etc.)

4) Búsqueda de una composición. Se proporcionará una pantalla distinta para la

búsqueda de composiciones ya que poseen propiedades propias como por ejemplo “ambiente” o “tipos de componentes”.


- 106 -

4.3.2. FASE DE DISEÑO En todo proyecto software es muy importante la fase de diseño, facilita la

descomposición del sistema en subsistemas para construir e implementar los diferentes casos de uso definidos en la fase de análisis.

Existen varias técnicas para realizar el diseño de un sistema software. La técnica

elegida en este caso es la orientada a objetos. Es la técnica más utilizada en la actualidad. Se realiza un diseño del sistema desde el punto de vista de la programación orientada a objetos, y tiene como elementos principales las clases y las relaciones entre ellas. A diferencia de un diseño relacional, donde el diseño se realiza desde el punto de vista de una base de datos relacional.

Se utilizará el estándar UML (Unified Modeling Language) para modelar el

sistema. Éste estándar reúne una colección de técnicas que permiten especificar, visualizar, construir y documentar los elementos del sistema.

4.3.2.1.Diseño de la Aplicación

En este apartado se expondrán los objetos definidos para el correcto funcionamiento del sistema. Una vez elegida la técnica de diseño del sistema, se procede a definir los objetos necesarios para el correcto funcionamiento de la aplicación y las relaciones entre ellos. Se ha diseñado el sistema intentando separar lo que es propio de nuestra aplicación de las funcionalidades genéricas que podrían ser reutilizables en otros proyectos relacionados con ontologías. Por ello, se han creado tres paquetes principales con utilidades distintas. En la figura 4.14. se pueden ver los paquetes y las clases que contiene cada uno.


- 107 -

Figura 4.23 Vista de todos los objetos del sistema.

1) Paquete “UI”. Contiene las clases responsables de crear y manejar los componentes del interfaz de usuario:

Clase AppletUI. Esta clase será la encargada de construir todos los

componentes del interfaz y lanzar el applet. Así como de añadir escuchadores a los componentes. En esta clase se definirán todos los componentes visuales del interfaz (paneles, botones, cajas de texto, etc.). Contendrá los métodos del ciclo de vida de un applet, un método que se encargue de añadir escuchadores a los componentes y todos los getters de los componentes visuales que permitirán obtenerlos y manejarlos.

Clase HandlerUI. Esta será la clase encargada de manejar la interfaz

de usuario. Se relaciona con todas las demás clases del sistema, actuando de puente entre las clase que contiene la definición del applet y el resto de clases. Contendrá todos los métodos que implementan acciones de respuesta a eventos. Inicializa los componentes del interfaz y realiza la llamada al método que carga el modelo de ontología, y posteriormente al método que construye un árbol (JTree) con las clases de la ontología que cuelgan de la clase


- 108 -

Product, para mostrarlo en el interfaz, permitiendo al usuario elegir exactamente el tipo de producto que busca.

2) Paquete “Ontology”. Contiene las clases que se encargan de cargar el

modelo de la ontología y de acceder a este realizando peticiones y operaciones:

Clase LoaderOntology. Implementa los métodos de carga del

modelo de ontología. En esta clase se definen todos valores necesarios para crear el modelo de ontología, desde fichero owl y desde almacenamiento persistente (namespace, nombre del modelo, usuario de la base de datos, etc.). Además de estos atributos, tendrá un atributo de tipo OntModel, que es donde se almacena el modelo de ontología cargado.

Clase ClientOntology. Esta clase contendrá métodos genéricos que

extraen información de la ontología y la devuelven al manejador para mostrarla en el interfaz. Implementa funciones como convertirOntologiaEnArbol(nombreRaiz), que convierte las clases de la ontología que cuelgan de la clase “nombreRaiz” en nodos de un árbol en java. Esta funcionalidad podría resultar útil en cualquier otro proyecto, de modo que se desarrolla de manera genérica pudiendo ser reutilizada en otros trabajos.

3) Paquete “Consultant”. Contiene la clase que implementa las consultas

SPARQL con las búsquedas que desea realizar el usuario:

Clase QueryOntology. En esta clase será donde se construyan las consultas SPARQL embebidas en Jena, y donde se ejecuten devolviendo los resultados a la clase HandlerUI, que es la que se encarga de formatearlos y mostrarlos en el interfaz.

4.3.2.1.1. Diagrama de clases

En la siguiente figura se muestra el diagrama que representa los objetos definidos para el desarrollo de la aplicación junto con las relaciones entre ellos. Se trata de una versión reducida del diagrama de clases del sistema que contiene los atributos y métodos más relevantes de cada clase (el diagrama de clases completo, con todos los métodos y atributos se puede ver en el fichero “Aplicación.eap” que se encuentra en el CD que acompaña esta memoria).


- 109 -

Figura 4.24 Diagrama de clases de la aplicación. En el apartado de implementación se verán con más detalle los métodos y atributos de las clases implementadas. 4.3.2.1.2. Diagrama de secuencia

A continuación se muestran los diagramas de secuencia de los principales

escenarios de uso del interfaz.


- 110 -

Realizar búsqueda

Figura 4.25 Diagrama de Secuencia del escenario “Realizar Búsqueda”

Precondiciones: El Usuario debe de haber elegido el tipo de producto que desea buscar.

El Usuario debe de haber indicado las características del producto a

buscar.

El Usuario debe de haber pulsado el botón buscar.

Poscondiciones: Si la consulta devuelve resultados, se formatearán y se mostrará la lista

de productos al usuario.

Si no hay resultados disponibles se devolverá un mensaje al usuario.


- 111 -

Obtener detalles de un producto

Figura 4.26 Diagrama de Secuencia del escenario “Obtener detalles”

Precondiciones: El Usuario debe haber realizado la búsqueda.

El Usuario debe haber seleccionado un producto de la lista de resultados.

Poscondiciones: El sistema extrae información sobre el producto elegido y se la muestra

al usuario.


- 112 -

4.3.2.2.Diseño de la Interfaz de Usuario

El interfaz de usuario se puede diseñar de muchas maneras. Debemos pensar en la comodidad del usuario, y en ofrecerle un interfaz de fácil uso minimizando al máximo los tiempos necesarios para el aprendizaje. Antes de comenzar, se consultó la lista de los buscadores web semánticos que ya están operativos actualmente (http://www.javi.it/semantic.html). Entre los que hay, se destacan algunos que han aportado algunas ideas para el diseño de nuestra interfaz gráfica:

Quintura (www.quintura.com) es uno de los más perfeccionados. Muestra como una nube de palabras relacionadas que con solo pasar el ratón sobre ellas te pueden ayudar a afinar los resultados.

Ujiko (www.ujiko.com), este tiene una bonita apariencia y por su modo de búsqueda, a medida que vas buscando te ofrece diferentes opciones para encaminar la búsqueda hacia un tema u otro.

WebRain (www.webbrain.com), este muestra un mapa de grupos bien

relacionados con las palabras que buscas, y bastante útiles. Visto esto, se sacaron unas ideas generales para el diseño de la interfaz:

Mostrar los diferentes tipos de muebles para que el usuario pueda elegir el que quiera. Se ha pensado en extraer la jerarquía de clasificación de los muebles de la ontología y volcarla al interfaz en una estructura de árbol por ejemplo.

Encaminar la búsqueda según el tipo de mueble elegido, ofreciendo una serie de características que el usuario pueda ir especificando con los valores que desea. Una manera simple e intuitiva de realizarlo sería mediante desplegables.

Teniendo en cuenta las ideas anteriores y las especificaciones de la aplicación

Web estudiadas en la Fase de Análisis se realiza el diseño distinguiendo 3 partes en la interfaz por la ubicación que tendrán dentro de ésta y por el contenido que se mostrará en cada una de ellas:

1) La primera parte es la situada en la zona superior izquierda de la interfaz y

contendrá un árbol de los productos que se pueden buscar. Al principio, se muestra solo el nodo raíz (que es Producto) y el primer nivel del árbol (que contiene los conceptos Mueble y Composición). Luego el usuario podrá ir desplegando aquellos nodos (productos) que le interesen y seleccionar el tipo de producto exacto que desea encontrar.

2) La segunda parte es la situada en la zona superior derecha de la interfaz y contiene el panel principal donde se muestran los desplegables con las propiedades correspondientes al tipo de producto seleccionado por el usuario, y el botón de búsqueda. La primera vez que se acceda a la


- 113 -

aplicación esta parte contendrá un panel con las propiedades genéricas que puede tener cualquier producto, luego cuando el usuario elige un tipo de mueble o una composición se mostrará el panel correspondiente al tipo seleccionado.

3) La tercera parte es la zona inferior donde se muestran los resultados de la

búsqueda. Esta parte se divide a su vez en dos subpartes: un panel que muestra la lista de productos resultado de la consulta; y otro panel que se mostrará debajo cuando el usuario solicite obtener información detallada sobre un producto específico de la lista de resultados.

Figura 4.27 Interfaz de usuario

CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS

- 114 -


- 115 -

5. IMPLEMENTACIÓN Y PRUEBAS

5.1 FASE DE IMPLEMENTACIÓN Tras analizar y establecer el diseño de la programación de la aplicación, se dispuso a codificarla. Para ello se tomaron una serie de decisiones de implementación teniendo en cuenta los requisitos establecidos en el apartado de análisis: La primera decisión a tomar es la plataforma de desarrollo que se va a utilizar. El

grupo de trabajo del departamento Tecnologías de la Información donde se ha desarrollado el proyecto hace uso actualmente de un entorno Java para la programación, sobre todo en el desarrollo de las herramientas de catalogación basadas en el estándar funStep. De modo que fue Java la plataforma de desarrollo utilizada, por este motivo y por otros más motivos dignos de ser analizados:

1) Java es orientado para la web, su estructura comparte la esencia de la estructura de la Web Semántica.

2) Nos ofrece multiplataforma. El código generado es de alta calidad, muy

reutilizable y muy extensible.

3) Las herramientas que se han convertido en estándares de facto para trabajos con web semántica como Jena o Sesame, se basan ambas en la tecnología Java.

La siguiente decisión a tomar es qué arquitectura utilizar para el desarrollo de la

aplicación. Teniendo en cuenta que ha de ser accesible vía web, se han barajado dos opciones:

1) La arquitectura J2EE basada en el patrón Modelo Vista Controlador (MVC), donde la vista es la página HTML y el código que provee de datos dinámicos a la página; el modelo es la lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. Esta opción es interesante para el desarrollo de aplicaciones web con sofisticados interfaces, ya que trata de realizar un diseño que desacopla la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma, las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos. Debido a que el desarrollo de una aplicación J2EE tiene un coste de desarrollo considerable y a que la aplicación que se pretende diseñar no será demasiado compleja, no se ha optado por esta opción.

2) Mediante un Applet en java. Un applet es un componente de una

aplicación que se ejecuta en el contexto de otro programa, por ejemplo un navegador web. Un Java applet se puede cargar y ejecutar desde cualquier explorador que soporte JAVA (Netscape, Internet Explorer de


- 116 -

Windows, Mozila Firefox, etc.). Es menos costoso diseñar el interfaz de esta manera, y el resultado obtenido cumplirá con los requisitos establecidos, por lo cual, se utilizó Java applet para desarrollar la aplicación.

El entorno de trabajo escogido para trabajar con semántica fue Jena 2. Es una

plataforma de trabajo que ofrece un entorno de desarrollo estable y potente donde poder trabajar con RDF, RDF Schema y OWL. Incluye un parser de RDF, una API de RDF, una API de ontologías escritas en OWL, DAML y RDFS, un subsistema de razonamiento, el lenguaje de búsquedas RDQL y SPARQL, así como un subsistema de persistencia. El subsistema de persistencia trabaja con MySQL, Oracle y PostgreSQL, por lo que cualquier BD de ese tipo puede ser el repositorio de hechos (la base de datos donde se almacenará la información). El único sistema de almacenamiento que puede competir con Jena actualmente es Sesame, que es un marco de desarrollo para almacenamiento, consulta y razonamiento con RDF y RDF Schema. Puede ser usado como base de datos para RDF y RDF Schema, o como una librería de Java para aplicaciones que necesitan trabajar internamente con RDF. Sin embargo, todavía no es compatible con OWL, y por ello se eligió Jena 2.

Se utilizó un plugin de Protégé, Protégé2Jena (Prot2Jena, 2006) para exportar la ontología a almacenamiento persistente, utilizando el sistema gestor de bases de datos MySQL. Y mediante Jena se procederá a cargar un modelo de la ontología desde almacenamiento persistente, al que posteriormente podremos atacar tanto para leer, modificar, crear o realizar búsquedas.

Las búsquedas se llevarán a cabo mediante consultas embebidas en Jena. Entre los lenguajes de consulta que incluye Jena, SPARQL y RDQL, se consideró que es mejor SPARQL por una serie de motivos:

Es muy rápido y permite obtener resultados de las búsquedas como

grafos de RDF.

RDQL es anterior a las especificaciones definitivas de RDF, por lo que hay algunas inconsistencias. Por ejemplo, se ha encontrado con que RDQL maneja enteros sin comprobar el tipo de datos.

SPARQL añade funciones que RDQL no tiene: permite ordenar los

resultados, comprobar más expresiones (tiempo y fechas, por ejemplo), usar grafos con nombres, etc.

La sintaxis de SPARQL es muy sencilla.


- 117 -

5.1.1. Implantación de la Ontología en la Aplicación

Como se ha comentado en el apartado anterior, se utilizó la plataforma Jena para el desarrollo del sistema. Lo primero que se debe realizar es cargar un modelo de ontología que nos permita manejar la ontología y acceder a ella para resolver las peticiones del usuario. Un modelo de ontología es una extensión del modelo RDF de Jena que provee capacidades adicionales para manejar ontologías. Los modelos de ontología se crean a través de la clase “ModelFactory” de Jena. Una forma simple de crear un modelo de ontología es la siguiente: OntModel m = ModelFactory.createOntologyModel(); Esto crea un modelo de ontología con las especificaciones por defecto, que son las siguientes:

Lenguaje OWL_Full Almacenamiento en memoria Inferencia RDFS, que principalmente produce hechos a partir de las jerarquías

sub_class y sub_property. Para manejar nuestra ontología se crea el modelo con una configuración específica, a través del objeto OntModelSpec de la clase OntModelSpec de Jena. Las especificaciones son las siguientes:

Lenguaje OWL_DL Almacenamiento en memoria. Razonador basado en reglas OWL.

Al crear el modelo se obtiene un objeto de tipo OntModel, que es el que se utilizará para manejar la ontología y para realizar las consultas formuladas a partir de las peticiones del usuario. Se han implementado dos métodos que cargan la ontología a partir del modelo creado de formas distintas:

1) El método loadOntologyFromOWL() que se corresponde con la carga de la ontología desde fichero OWL. Veamos lo que hace este método:

public void loadOntologyFromOwl() { java.io.InputStream in = FileManager.get().open(OWL_FILE); if (in == null){ throw new IllegalArgumentException("Archivo no

encontrado"); }


- 118 -

modelOnt=ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM_RULE_INF);

// leer el archivo OWL modelOnt.read(in, ""); }

Como se puede ver en el trozo de código anterior lo que se realiza es lo siguiente:

a) Abrir el fichero OWL que contiene la definición de la ontología y las

instancias.

b) Crear un modelo de la ontología como se ha explicado anteriormente.

c) Leer el fichero de la ontología desde el modelo creado.

2) El método loadOntologyFromDB(), que carga la ontología desde almacenamiento persistente. Para esto, previamente se exporta la ontología a almacenamiento Jena persistente desde Protégé utilizando el plugin Protégé2Jena como ya se ha comentado. El código para implementarlo sería:

public void loadOntologyFromDB() {

IDBConnection conModel = new DBConnection(URL_DB, USER_DB,

PWD_DB, "MySQL"); ModelMaker maker = ModelFactory.createModelRDBMaker(conModel);

ModelRDB model = (ModelRDB) maker.openModel(MODEL_NAME); try {

modelOnt=ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM_RULE_INF, model);

} catch (Exception e) { e.printStackTrace(); } }

a) Se crea la conexión con el modelo persistente.

b) Se abre el modelo desde el almacenamiento persistente.

c) Se crea el modelo utilizando como razonador OWL_DL_MEM_RULE_INF


- 119 -

5.1.2. Notas de implementación

Una vez cargada la ontología en la aplicación, ésta podrá acceder a ella para leer, modificar, crear o bien buscar información. Se recogerán las peticiones del usuario del interfaz y se convertirán en consultas SPARQL que se ejecutarán sobre el modelo de ontología devolviendo unos resultados que serán formateados y finalmente, mostrados al usuario.

En este apartado se va a describir un poco cómo se han implementado los

métodos más relevantes de cada una de las clases implementadas para llevar a cabo todas las funcionalidades del sistema.

Clase AppletUI:

El método init() es donde se definen todos los componentes de la

interfaz gráfica utilizando la librería swing de java. Nuestro interfaz de usuario contiene básicamente los siguientes componentes: Un JTree que permite navegar por la jerarquía de muebles y

seleccionar un tipo específico.

Dos paneles principales:

“JPPieceOfFurn” para la búsqueda de muebles individuales, tales como silla, cama, mesa, etc. Luego, según si el tipo de mueble seleccionado sea una mesa, cama, asiento o mueble de almacenamiento se visualizará un panel con propiedades específicas del tipo de mueble seleccionado. Así por ejemplo, si el usuario lo que busca es una mesa, seleccionará mesa en el árbol, y automáticamente se cargará el panel específico de mesa, que contiene propiedades específicas de una mesa como forma y tipo de base. Si en cambio, busca un armario, se visualizará un panel que permite dar valores a propiedades como “número de cajones” o “número de puertas”.

“JPCompProperties” para la búsqueda de composiciones

(compuestas de varios muebles). En este panel el usuario podrá elegir valores de propiedades propias de una composición, como ambiente (noche, salón, cocina, etc.) o tipos de muebles que la componen.

Una serie de comboBoxes y cajas de texto para que el usuario pueda

seleccionar o introducir los valores de las propiedades de los muebles que busca.

El método start() realiza la llamada al método startUI de la clase

HandlerUI, que inicializa los componentes del interfaz y añade escuchadores de eventos a los componentes.


- 120 -

El resto de métodos son getters de todos los atributos definidos en la clase. Devuelven referencias a los componentes del interfaz.

Clase HandlerUI:

startUI() llama a uno de los métodos de la clase LoaderOntology que

cargan el modelo de ontología, a continuación al método crearArbol() el cual invoca métodos de la clase ClientOntology que recorren de manera recursiva la jerarquía de clases de la ontología y crean una estructura de árbol en java. Y finalmente, llama al método inicializar().

inicializar() se encarga de inicializar los componentes del interfaz, los

comboBoxes se rellenan con los valores correspondientes al rango de la propiedad que representan. Por lo que se hacen llamadas a los métodos obtainInstancesOfClass() y obtainSubclassesOfClass() de la clase ClientOntology, que acceden a la ontología y rellenan los comboboxes.

El método crearArbol() como se ha comentado antes, crea un árbol en

java con los conceptos de la ontología. Para ello, llama al método convertirOntologiaEnArbol() de la clase ClientOntology pasándole el nombre de la clase raíz a partir de la cual se quiere construir el JTree.

actionTree() implementa el código que debe ejecutarse cuando el

usuario selecciona un nodo del árbol de muebles. Básicamente, lo que debe hacer el sistema es comprobar qué tipo de mueble ha sido seleccionado por el usuario para mostrar el panel de propiedades adecuado, para que el usuario pueda seguir afinando su búsqueda especificando las características del mueble que busca.

actionSearch() implementa el código que se ejecuta cuando el usuario

pulsa el botón search. En la Fase de Diseño se vio el diagrama de secuencia del escenario “Realizar búsqueda de un mueble”, que representa las interacciones entre los objetos que tienen lugar a lo largo del tiempo cuando se ejecuta esta acción.

Cuando lo que busca el usuario es una composición (caso de uso “Buscar composición”) la secuencia de interacciones es muy parecida a la que se muestra en la figura 4.24. Intervienen los mismos objetos, solo que, el manejador recogería los parámetros de búsqueda de los componentes del panel JPCompProperties en vez de JPPieceOfFurn, y en lugar de llamar al método findPieceOfFurn(ArrayList<String>) de la clase QueryOntology, llamaría a la función findComp(ArrayList<String>). Luego, en ambos casos, se devuelven los resultados de la consulta al handler, y éste se encarga de formatearlos y mostrar el panel de resultados al usuario. Inicialmente, se muestra una tabla que lista los muebles encontrados en la base de conocimiento resultado de la búsqueda del usuario. En la tabla solo se mostrará información básica sobre los muebles, como material y precio. Si el usuario desea obtener más detalles sobre algún mueble en particular deberá seleccionar dicho producto de la tabla de resultados.


- 121 -

Las funciones findPieceOfFurn() y findComp() construyen la consulta

SPARQL a partir de los parámetros recogidos del interfaz, y la ejecutan. Se construye la cadena con toda la consulta SPARQL, se pasa la cadena a la función create(queryString) de la clase QueryFactory de Jena. Luego se llama a la función create de QueryExecutionFactory pasándole la query y el modelo de ontología, y finalmente se ejecuta la consulta y se obtienen los resultados con la llamada:

ResultSet results = qe.execSelect();

actionTable() implementa el código que ha de ejecutarse cuando se

detecta el evento de seleccionar una fila de la tabla de resultados, es decir, cuando el usuario desea obtener más información sobre un determinado mueble o composición. El handler obtiene la fila seleccionada por el usuario y consigue una referencia a la instancia de mueble correspondiente. Luego llama al método queryIndividual(String) de la clase QueryOntology, que accede a la ontología y obtiene los valores de una serie de propiedades sobre el mueble a través de consultas SPARQL, y los devuelve al handler. Éste recoge los valores devueltos, los formatea y los muestra al usuario en el panel de detalles.


- 122 -

5.2 PRUEBAS Y EVALUACIÓN 5.2.1. Fundamentos de la prueba

Cuando se desarrolla un sistema software existen enormes posibilidades de que

se produzcan fallos humanos en las actividades de producción. Pueden darse errores en cualquier fase del proceso, desde una mala especificación de los objetivos, hasta errores en las fases de diseño y desarrollo.

Es imposible que el ser humano trabaje de una manera perfecta, y por ello, el

desarrollo debe ir acompañado de una actividad que garantice la calidad. Así pues, la prueba del software representa la revisión final de las especificaciones, del diseño y de la codificación.

La fase de pruebas del sistema tiene como objetivo verificar el sistema software

para comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc. En este caso, dado que el sistema desarrollado consiste en una aplicación con interfaz gráfica, se deben realizar pruebas funcionales que verifiquen que el sistema software ofrece a los actores humanos la funcionalidad recogida en su especificación.

5.2.2. Pruebas del sistema

Uno de los objetivos de la fase de pruebas del sistema es verificar que el

comportamiento externo del sistema software satisface los requisitos establecidos por los clientes y futuros usuarios del mismo.

Toda prueba consta tradicionalmente de tres elementos:

1) Interacciones entre el sistema y la prueba 2) Valores de prueba 3) Resultados esperados.

Los dos primeros elementos permiten realizar la prueba y el tercer elemento

permite evaluar si la prueba se superó con éxito o no. Una de las técnicas más empleadas para la especificación funcional de sistemas

software son los casos de uso. Caso de uso “Especificar tipo de producto” Fundamentos: El usuario accede a la aplicación y desea buscar un tipo

específico de mueble. Va desplegando el árbol de muebles que aparece en la zona lateral izquierda del interfaz y pulsa sobre el tipo de mueble que quiere.


- 123 -

Caso de prueba 1: El usuario desea buscar composiciones. Ver figura 5.1.

Caso de prueba 2: El usuario desea buscar camas de matrimonio.

Ver figura 5.2.

Resultado: El sistema muestra en cada caso el panel correspondiente con las propiedades del tipo de mueble elegido por el usuario.

Conclusión: Prueba superada con éxito. Se muestra el panel

correspondiente al tipo de mueble seleccionado de manera correcta, como se puede comprobar en las figuras 5.1. y 5.2.

Figura 5.1 Prueba – El usuario elige buscar Composiciones.


- 124 -

Figura 5.2 Prueba – El usuario elige buscar Camas Dobles.

Caso de uso “Realizar Búsqueda” Como se puede ver en el diagrama de casos de uso del capítulo anterior, este caso de uso es muy genérico e incluye la búsqueda de todos los productos disponibles (muebles individuales o composiciones), por varias características. Se van a mostrar algunos ejemplos de diferentes búsquedas. Fundamentos: El usuario selecciona los valores que desea de las

propiedades del mueble elegido previamente a través de los desplegables y pulsa el botón de buscar.

Caso de prueba 1: El usuario busca muebles de un fabricante

específico, destinados para dormitorios, de estilo moderno, en Valencia. Ver figura 5.3.

Caso de prueba 2: El usuario busca conjuntos de salón con componentes de almacenaje, y que tengan un precio entre 1.000 € y 3.000 €. Ver figura 5.4.

Caso de prueba 3: El usuario busca composiciones de “ambiente

noche” con cama. Ver figura 5.5.


- 125 -

Caso de prueba 4: El usuario busca camas individuales con base de somier, de estilo moderno y con cabecero, en Valencia. Ver figura 5.6.

Caso de prueba 5: El usuario busca modelos de sillas de estilo

moderno en tiendas de Valencia ciudad. Ver figura 5.7.

Caso de prueba 6: El usuario busca sillas en Valencia de estilo vanguardista y que tengan un precio inferior a 300€. Ver figura 5.8

Caso de prueba 7: El usuario busca mesas de salón cuadradas de

estilo moderno. Ver figura 5.9. Resultado: El sistema muestra el panel de salida con la lista de muebles

resultado de cada búsqueda.

Conclusión: Prueba superada con éxito. El sistema devuelve una tabla con los resultados de la búsqueda de forma inmediata. En las figuras 5.3, 5.4, 5.5, 5.6 y 5.7 se pueden ver distintos ejemplos de búquedas realizadas.


- 126 -

Figura 5.3 Ejemplo de búsqueda de muebles de un Fabricante


- 127 -

Figura 5.4 Ejemplo de búsqueda de Conjuntos de salón


- 128 -

Figura 5.5 Ejemplo de búsqueda de Composiciones con camas


- 129 -

Figura 5.6 Ejemplo de búsqueda de camas individuales con cabecero


- 130 -

Figura 5.7 Ejemplo de búsqueda de Sillas modenas en Valencia ciudad


- 131 -

Figura 5.8 Ejemplo de búsqueda de Sillas con un rango de precio


- 132 -

Figura 5.9 Ejemplo de búsqueda de Mesas de salón cuadradas

Caso de uso “Obtener detalles de un producto”

Fundamentos: El usuario pulsa sobre un resultado de la lista del panel de resultados solicitando información detallada sobre un producto.

Resultado: El sistema muestra el panel de detalles con la información detallada sobre el producto seleccionado.

Conclusión: Prueba superada con éxito. Se puede ver en las figuras 5.10,

5.11, 5.12, 5.13 y 5.14 los resultados de las consultas de información sobre los productos seleccionados en las figuras 5.4, 5.5, 5.6, 5.7, 5.8 y 5.9 respectivamente.


- 133 -

Figura 5.10 Obtener detalles del producto “Bedroom Syros 2”

Figura 5.11 Obtener detalles del producto “Diez4 Single Bed”


- 134 -

Figura 5.12 Obtener detalles del producto “Carlotta Chair”

Figura 5.13 Obtener detalles del producto “Dubai Chair”


- 135 -

Figura 5.14 Obtener detalles del producto “Javea Table 031”


- 136 -

5.2.3. Pruebas de Consistencia en la Ontología

A parte de las pruebas funcionales del sistema desarrollado, se han realizado pruebas de consistencias en la Ontología que se van exponer en este apartado.

Para llevar a cabo esta tarea se ha utilizado el razonador RacerPro (RacerPro,

2009). Es un razonador basado en el lenguaje Lisp y es compatible con OWL_DL.

Al lanzar el razonador por primera vez se detectaron una serie de inconsistencias que hubo que solventar (Ver figura 5.15).

Figura 5.15 Inconsistencias detectadas con Racer-Pro.

Principalmente, se descubrió que gran parte de las inconsistencias que da se deben a los siguientes tipos de restricciones en la definición de las clases:

La restricciones de tipo “hasCapacity has 2” No se puede restringir el valor de una propiedad de tipo entero.

La restricciones de tipo “hasCastors has true” no las entiende el razonador, da warning (aviso).

Estas inconsistencias se deben a que en OWL_DL no se puede restringir el valor


- 137 -

de una propiedad de tipo Datatype (tipo de dato), solo se pueden usar restricciones hasValue para propiedades de tipo Object.

Finalmente, después de solucionar las inconsistencias que se habían detectado se obtuvo la versión final de la ontología sin inconsistencias como se puede ver en la figura 5.16.

Figura 5.16 Chequeo de consistencia de la ontología con RacerPro

CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO

- 138 -


- 139 -

6. CONCLUSIONES Y TRABAJO FUTURO

6.1. Conclusiones

En este apartado se abordan las conclusiones extraídas y los resultados obtenidos durante el desarrollo del proyecto.

En primer lugar, puede afirmarse que se ha cumplido el primer objetivo principal

de este proyecto: desarrollar una ontología que defina formalmente y relacione los conceptos del dominio de muebles y afines, y que esté basada en el estándar internacional funStep (ISO 10303-236). Antes de comenzar el desarrollo de la ontología se realizó un análisis del modelo de datos de ISO funStep para extraer aquellos conceptos del ámbito de la ontología del mueble y afines y realizar su transcripción semántica, como se puede comprobar en el capítulo de Proceso de Ingeniería de esta memoria.

Se ha conseguido, en segundo lugar, establecer una base de conocimientos de

muebles y afines que represente el formato funStep de manera semántica, generando con ello un marco de fácil actualización y extensibilidad. Durante el periodo de desarrollo de la ontología, ésta ha sido revisada periódicamente por expertos en el sector (técnicos de AIDIMA y trabajadores especializados de empresas); y tras su finalización se envió una primera versión a las empresas colaboradoras en funStep (Grupo de Interés funStep), que la consideraron satisfactoria y útil para el sector. La ontología cumple con los requisitos establecidos.

En la industria del mueble y afines existe un importante problema de falta de

interoperabilidad; el cual dificulta enormemente el intercambio de información entre fabricantes, distribuidores, comercios y clientes, y ralentiza el lanzamiento de nuevos productos al mercado. Para solucionarlo, bastaría que las empresas del sector usaran el vocabulario creado de manera común y unificada. Debido al peso y a la influencia de AIDIMA entre estas empresas, es segura la utilización de la ontología por muchas de ellas. La ontología conseguida es lo bastante completa y detallada como para responder a las necesidades del sector; en todo caso, los distintos miembros del Grupo de Interés funStep la ampliarán y mejorarán en el futuro.

Actualmente se está comenzando a integrar la ontología en otro proyecto

desarrollado por AIDIMA: la herramienta de definición e intercambio de información de catálogos (Cadef). Con Cadef se pretende enlazar los productos de un catálogo electrónico a los conceptos definidos en la ontología, y en consecuencia extraer de ella las propiedades asociadas a cada producto. Con esto, se consigue por una parte identificar a cada producto con una URI, lo cual permite su localización; por otra parte, esto constituye el primer paso para aprovechar los productos de los catálogos generados por Cadef importándolos como instancias de las clases de la ontología, lo cual ampliaría la base de conocimientos desarrollada en este proyecto y evitaría el esfuerzo de tener que introducir a mano las instancias. El siguiente paso estribaría en desarrollar una herramienta que traduzca la información de los catálogos generados con Cadef en XML a OWL.


- 140 -

En tercer lugar, en el proyecto se ha conseguido desarrollar el prototipo funcional de una aplicación web de búsqueda de información dirigida al sector mobiliario basada en la ontología desarrollada; prototipo que permite realizar consultas de gran interés para los usuarios, según se establecieron con expertos del sector.

Al tratarse de un prototipo, la cantidad de información que se maneja es

relativamente pequeña en comparación con la gran cantidad de muebles, accesorios y materiales de la industria. Por ello, las pruebas del prototipo se han realizado cargando el modelo de la ontología desde un fichero OWL. Para que el prototipo de buscador pueda utilizarse con un buen rendimiento en el futuro, cuando se incorporen más productos, se ha implementado también la manera de hacerlo desde almacenamiento persistente. Por eso, se ha utilizado la herramienta Jena, que incluye un subsistema de persistencia. Si se llevara a cabo esa aplicación en el futuro, habría que incluir una base de datos para almacenar la información.

A la hora de decidir la manera de implementar la interfaz, se propusieron dos

opciones: desarrollarla mediante un applet o mediante una aplicación J2EE. Cabe mencionar que, en esta parte, lo importante para la empresa era aplicar las tecnologías semánticas para implementar las búsquedas que los usuarios desean realizar y conseguir una interfaz sencilla que permitiera interactuar de forma cómoda y sencilla con el sistema y probarlo. La idea es utilizarlo, de momento, como herramienta para presentar las posibilidades de la ontología a las empresas del sector; y con ello, fomentar su uso común para catalogación electrónica, integración automática de catálogos electrónicos de distintos fabricantes, anotación semántica de recursos relacionados con muebles e introducción de muebles y complementos en marketplaces. Es decir, el objetivo no era conseguir una interfaz atractiva ni avanzada. Por ello, después de haber desarrollado la ontología, se decidió realizarlo mediante un applet en Java.

A pesar de usar un applet, se ha mantenido una separación entre la vista y la lógica de negocio con el objetivo de mejorar la reusabilidad, de modo que en el futuro se pueda modificar el interfaz de la aplicación y reutilizar los paquetes que contienen toda la lógica de acceso a la información y de las consultas. La aplicación final desarrollada ha resultado plenamente satisfactoria para el jefe de proyecto, D. Miguel Ángel Abián, al igual que para la directora –Dña. María José Nuñez–. Se realizó una demostración final en AIDIMA, a la que asistieron representantes de varias empresas del sector, que después de probar la aplicación mostraron su interés en adoptar la ontología para describir y clasificar los productos de sus catálogos. Como se explica en el apartado 6.2, se prevé trabajar en el parseo de los catálogos desde XML a OWL para poder realizar la carga automática de los datos y poder llevar el prototipo a aplicación industrial.


- 141 -

6.2. Trabajo Futuro

Este proyecto ha incorporado por primera vez las tecnologías semánticas al sector del mueble y afines. Es un comienzo para lograr, por una parte, la interoperabilidad completa entre los SI de las empresas del sector; y, por otra parte, para mejorar la búsqueda de información, consiguiendo búsquedas más eficaces y mejor adaptadas a las necesidades de los usuarios.

La ontología creada podrá extenderse con nuevos conceptos y relaciones, según

los requerimientos de las empresas colaboradoras. Está prevista ya su utilización combinándola con las herramientas de anotación semántica desarrollados en el proyecto europeo ATHENA (Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications), para anotar semánticamente imágenes, dibujos o diseños de muebles, procedentes de catálogos de fabricantes, distribuidores o de recursos de la web.

En cuanto a la aplicación web, se puede pasar de un prototipo a una aplicación

industrial. Para ello, ya se está trabajando en lo siguiente:

1. Mediante la herramienta Cadef, enlazar los productos de los catálogos con los conceptos de la ontología. Hasta el momento se ha programado una versión beta del Cadef que enlaza con la ontología y extrae las propiedades correspondientes a cada producto. En la figura 6.1. se puede ver una captura de pantalla de la nueva implantación de Cadef.

2. Desarrollar una herramienta que analice los catálogos en XML, generados por Cadef, y transformarlos a ficheros OWL, para poder importarlos a la ontología. Así se logrará ampliar la base de conocimientos a la cual accede la aplicación para resolver las consultas de los usuarios.

Por último, se prevé pasar la aplicación a una arquitectura J2EE basada en el

patrón MVC (Modelo Vista Controlador) y obtener una interfaz más avanzada convirtiendo el código a JSP o adaptándolo a las nuevas tecnologías usando frameworks de desarrollo como JSF.


- 142 -

Figura 6.1 Nueva implantación del Cadef (Versión beta).

BIBLIOGRAFÍA

- 143 -

BIBLIOGRAFÍA Abián Miguel Ángel (2005), El futuro de la Web. XML, RDF/RDFS, ontologías, y la Web semántica.La última versión se encuentra en http://wwwjavaHispano.org/licencias/. Aguado de Cea Guadalupe, Álvarez de Mon y Rego Inmaculada, Pareja Lora Antonio (2002), “Primeras aproximaciones a la anotación lingüístico-ontológica de documentos de la Web Semántica: OntoTag”, Revista Iberoamericana de Inteligencia Artificial, 17, 37-49. Alan Rector, Nick Drummond, Matthew Horridge, Jeremy Rogers, Holger Knublauch, Robert Stevens, Hai Wang y Chris Wroe, OWL Pizzas : Practical experience of teaching OWL-DL : Common Errors & Common Patterns, Department of Computer Science, University of Manchester, UK y Stanford Medical Informatics, Stanford University, Stanford, CA, USA. Alba Julio, (2007), “Qué es… la Web Semántica”, Las TIC en la sanidad, bit 163. Aldea A., Bocio J., Fensel D., Isern D., Gouzinis A., Gramajo J., Kokosis A., Moreno A., Politpu D. (2003), D2 – State of the Art KM technologies and practices, Information Societes Technology (IST) Programme. The h-TechSight Consortium. Beck Howard W. y Pinto H. Sofia, 2002, Overvew of Approach, Methodologies, Standars, and Tools for Ontologies, University of Florida y Universidade Técnica de Lisboa. Berners-Lee Tim, Hendler James and Lassila Ora (2001). The Semantic Web: A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities, Scientific American. Colin Piddington y Frank-Walter Jaekel, 2005, The Methodology to implement services and develop adoption actions towards SMEs, INTEROP. IPK-Berlin. Daconta Michael C., Obrst Leo J. and Smith Kevin T. (2003), The Semantic Web. A Guide to the Future of XML, Web Services and Knowledge Management. USA . Ed. Wiley Publishing, Inc., 232-237. DAML + OIL, 2001: http://www.daml.org/2001/03/daml+oil-index. Ultimo acceso el 24 de Junio de 2009. Gómez-Pérez Asunción, Fernández-López Mariano y Corcho Oscar (2002), OntoWeb: Ontology-based Information Exchange for Knowledge Management and Electronic Commerce .Technical Roadmap.Universidad Politécnica de Madrid. Kankaanpää Tomi(1999), Design And Implementation Of Conceptual Network And Ontology Editor. Helsinki University Of Technology. Magali Madelaine, Colin Piddington, Guy Doumeingts, Guillaume Vaugeois, Béatrix Barafort, Pierre Brimont,María José Núñez, Miguel Ángel Abián, Hervé Panetto, Kurt

BIBLIOGRAFÍA

- 144 -

Geihs y Richard Stevens (2004), The Methodology to implement services and develop take up actions towards SME’s, Deliverable D12.1, version 3.0. Horroks Ian, Ptef-Shneider Peter F., McGuinness Deborah L., Wetty Christofer A. (2006), OWL: A Description Logic Based Ontology Language for the Semantic Web. Matthew Horridge, Holger Knublauch, Alan Rector, Robert Stevens y Chris Wroe (Agosto 2004), A Practical guide to building OWL Ontologies using the Protégé-OWL plugin and CO-ODE tools Edition 1.0, The University of Manchester, Stanford University. Moreno Ortiz, Antonio (2000), Diseñño e implementación de un lexicón computacional para lexicografía y traducción automática.ISSN: 1139-8736. Disponible en http://elies.rediris.es/elies9/4-1.htm. Natalia F. Noy y Deborah L. McGuinness (Septiembre 2005), Desarrollo de ontologías-101:Guía Para Crear Tu Primera Ontología, Stanford University, Stanford, CA. Ontolingua, 2005: http://www.ksl.stanford.edu/software/ontolingua/. Ultimo acceso en Junio del 2009. Pellet (2009), The Pellet reasoner: http://clarkparsia.com/pellet . Último acceso el 1 de Julio de 2009. Protégé2Jena, 2006: http://semweb.krasu.ru/protege2jena/. Ultimo acceso el 6 de Junio de 2009. Racer (2009), The OWL Reasoner Racer-Pro: http://www.racer-systems.com/. Último acceso el 20 de Julio de 2009. Samper Zapater José Javier (2005), Ontologías para servicios web semánticos de información de tráfico: descripción y herramientas de explotación, tesis doctoral, Departamento de Informática, Universitat de València. Sánchez Fernández Luis y Fernández García Norberto (2005), Universidad de Carlos III de Madrid, “La Web semántica: fundamentos y breve estado del arte”, Novática: Revista de la Asociación de Técnicos de Informática, 178, 6-12. T. Berners-Lee, J. Hendler, O Lassila, (2001). The Semantic Web. Scientific American, May 2001. Sowa John F.(2000), Knowledge Representation. Logical, Philosofical and Computational Foundations. Ed Brooks Cole Publishing Co. 132-168. USA. Vallespir Bruno, Bourrieres Jean-Paul, Ducq Yves (2004), INTEROP NoE Project Presentaction. University Bordeaux. Xavier Polanco (2007), Université Pierre et Marie Curie de Francia, “Un modo de análisis de la infraestructura científica de las tecnologías de la información y de las comunicaciones”, Revista CTS 9 (3).

ANEXO I

- 145 -

ANEXOS

Anexo I: FurnitureOntology.owl

En este Anexo se muestran trozos de código OWL de la ontología generado con Protégé. El último trozo se corresponde con la definición de instancias.

<?xml version="1.0"?>  <rdf:RDF xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#" xmlns:xsp="http://www.owl-ontologies.com/2005/08/07/xsp.owl#" xmlns:p1="http://www.owl-ontologies.com/assert.owl#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://www.aidima.es/furnitureontology.owl#" xmlns:swrlb="http://www.w3.org/2003/11/swrlb#" xmlns:daml="http://www.daml.org/2001/03/daml+oil#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:p2="file://C:/FurnitureOntology/furnitureOntology#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:swrl="http://www.w3.org/2003/11/swrl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://www.aidima.es/furnitureontology.owl"> <owl:Ontology rdf:about=""> <rdfs:comment xml:lang="en">Furniture Ontology by Miguel Ángel Abián and Mouna Ziouziou</rdfs:comment> <protege:defaultLanguage rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >en</protege:defaultLanguage> <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >version 1.3</owl:versionInfo> … <owl:Class rdf:ID="Colour"> <owl:disjointWith> <owl:Class rdf:ID="Product"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Component"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Finish"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Ambient"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Weight"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Size"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Price"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Style"/>

ANEXO I

- 146 -

</owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Form"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Use"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Province"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Address"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Material"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Catalogue"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Organization"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:ID="DomainConcept"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Stand-upTable"> <rdfs:subClassOf> <owl:Class rdf:ID="RestaurantAndBarTable"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Taburete de bar</rdfs:comment> <rdfs:label xml:lang="en">Stand-up Table</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="RestaurantDiningTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="BanquetTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="CatteringBuffetTable"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="RockingChair"> <rdfs:label xml:lang="en">Rocking Chair</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >(Also "rocker"). A rocking chair or rocker is a chair with two curved bands of wood (also know as rockers) attached to the bottom of the legs (one on the left two legs and one on the right two legs). This gives the chair contact with the floor at only two points granting the occupant the ability to rock back and forth by shifting his/her weight or pushing lightly with his/her feet. Sometimes the rocking chair is on springs or on a platform (a "platform rocker").</rdfs:comment> <owl:disjointWith> <owl:Class rdf:ID="HomeOfficeChair"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="DomesticLoungeChair"/> </owl:disjointWith> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection">

ANEXO I

- 147 -

<owl:Class rdf:ID="DomesticChair"/> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="hasBase"/> </owl:onProperty> <owl:allValuesFrom> <owl:Class rdf:ID="Rocker"/> </owl:allValuesFrom> </owl:Restriction> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasBase"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="StoragePieceOfFurniture"> <rdfs:label xml:lang="en">Storage furniture</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="Screen"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Seat"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Table"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:ID="PieceOfFurniture"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="Bed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ChildrenPieceOfFurniture"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A piece of furniture intended to store items such as clothes, foods, etc.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#Door"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="CornerCupboard"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >In Spanish, "esquinera" or "rinconera".</rdfs:comment> <rdfs:label xml:lang="en">Corner Cupboard</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="BroomCupboard"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="FumeCupboard"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="LinenCupboard"/> </owl:disjointWith> <owl:disjointWith>

ANEXO I

- 148 -

<owl:Class rdf:ID="OtherCupboard"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Wardrobe"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Cupboard"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="SingleBed"> <rdfs:subClassOf> <owl:Class rdf:about="#Bed"/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:hasValue> <owl:onProperty> <owl:DatatypeProperty rdf:ID="hasNumberOfMattress"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="Bunk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="PullOutBed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="HospitalBed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="AirBed"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:allValuesFrom> <owl:Class rdf:ID="BedroomUse"/> </owl:allValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#BedroomUse"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="BunkBed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Stretcher"/> </owl:disjointWith>

ANEXO I

- 149 -

<owl:disjointWith> <owl:Class rdf:ID="CompactBed"/> </owl:disjointWith> <rdfs:label xml:lang="en">Single Bed</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="WaterBed"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:DatatypeProperty rdf:ID="hasCapacity"/> </owl:onProperty> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:hasValue> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#CompactBed"> <owl:disjointWith> <owl:Class rdf:about="#PullOutBed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#HospitalBed"/> </owl:disjointWith> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Bed"/> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="hasDesk"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:ID="HomeStudentDesk"/> </owl:someValuesFrom> </owl:Restriction> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> <owl:hasValue> <BedroomUse rdf:ID="YouthBedroomUse"> <rdfs:label xml:lang="en">Youth bedrooms</rdfs:label> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Youth bedroom</hasName> </BedroomUse> </owl:hasValue> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <owl:disjointWith> <owl:Class rdf:about="#WaterBed"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#AirBed"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Bed usually designed for young people or children that may consists of modular furniture; wardrobes, shelf units, desk, etc. all in the same structure together with the bed or

ANEXO I

- 150 -

beds</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#BunkBed"/> </owl:disjointWith> <rdfs:label xml:lang="en">Compact Bed</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#Stretcher"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#SingleBed"/> <owl:disjointWith> <owl:Class rdf:about="#Bunk"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Handle"> <owl:disjointWith> <owl:Class rdf:ID="MirrorFrame"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Backrest"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Component"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="Pilaster"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Armrest"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="SeatPart"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="VerticalSurface"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Base"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="HorizontalSurface"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Mattress"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Headboard"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="WritingTable"> <rdfs:subClassOf> <owl:Class rdf:ID="OfficeTable"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A writing table has a series of drawers directly under the surface of the table, to contain writing implements, so that it may serve as a desk.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:ID="OfficeDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="OtherOfficeTable"/>

ANEXO I

- 151 -

</owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="DrawingTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ConferenceTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ReceptionTable"/> </owl:disjointWith> <rdfs:label xml:lang="en">Writing Table</rdfs:label> </owl:Class> <owl:Class rdf:about="#HomeOfficeChair"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >(Also called home desk chair). A home oficce chair is a chair that is designed for use at a desk at home. A home office chair typically swivels, tilts, and rolls about on casters, or small wheels. Home office chairs, like office chairs, often have a number of ergonomic adjustments: seat height, armrest height and width, and back reclining tension.</rdfs:comment> <owl:disjointWith rdf:resource="#RockingChair"/> <owl:disjointWith> <owl:Class rdf:about="#DomesticLoungeChair"/> </owl:disjointWith> <rdfs:label xml:lang="en">Office Chair</rdfs:label> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#DomesticChair"/> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> <owl:hasValue> <OtherHomeUse rdf:ID="StudyOrOfficeHomeUse"> <rdfs:label xml:lang="en">Studies</rdfs:label> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Study or office use</hasName> </OtherHomeUse> </owl:hasValue> </owl:Restriction> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasBase"/> </owl:onProperty> <owl:allValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:ID="Swivel"/> <owl:Class rdf:ID="Leg"/> </owl:unionOf> </owl:Class> </owl:allValuesFrom> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="ServingTrolley"> <owl:disjointWith> <owl:Class rdf:ID="TVStand"/> </owl:disjointWith>

ANEXO I

- 152 -

<rdfs:subClassOf> <owl:Class rdf:ID="DomesticTable"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="EndTable"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Mobile table, usually provided with handles and wheels, with removalbe or fixed tray(s). In Spanish, "camarera".</rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</owl:hasValue> <owl:onProperty> <owl:DatatypeProperty rdf:ID="hasCastors"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="SofaTable"/> </owl:disjointWith> <rdfs:label xml:lang="en">Serving Trolley</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="HIFIStand"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#HomeStudentDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="CoffeeTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="LoungeTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="BedsideTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="DiningTable"/> </owl:disjointWith> </owl:Class> … <owl:Class rdf:about="#CommunionTable"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >The table in Christian churches where communion is given.</rdfs:comment> <rdfs:label xml:lang="en">Comunion Table</rdfs:label> <owl:disjointWith rdf:resource="#OtherReligiousTable"/> <owl:disjointWith> <owl:Class rdf:about="#Altar"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#ReligiousTable"/> </owl:Class> <owl:Class rdf:ID="OfficeWorkChair"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >(Also called "desk chair"). An office chair that is designed for use at a desk in an office. An office work chair typically swivels, tilts, and rolls about on casters, or small wheels. Office work chairs often have a number of ergonomic adjustments: seat height, armrest height and width, and back reclining tension. It may be very plushly upholstered and in leather and thus characterized as an executive chair, or come with a low back and be called a steno chair.</rdfs:comment> <rdfs:subClassOf>

ANEXO I

- 153 -

<owl:Restriction> <owl:onProperty> <owl:DatatypeProperty rdf:about="#hasCastors"/> </owl:onProperty> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</owl:hasValue> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="VisitorChair"/> </owl:disjointWith> <rdfs:label xml:lang="en">Work Chair</rdfs:label> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasBase"/> </owl:onProperty> <owl:allValuesFrom> <owl:Class rdf:about="#Swivel"/> </owl:allValuesFrom> </owl:Restriction> <owl:Restriction> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasBase"/> </owl:onProperty> </owl:Restriction> <owl:Class rdf:ID="OfficeChair"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="#Chest"> <owl:disjointWith rdf:resource="#Barrel"/> <owl:disjointWith> <owl:Class rdf:about="#Shelf"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Cabinet"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Cart"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A chest is typically a rectangular structure with four walls and a liftable lid, for storage or shipping. The interior space may be subdivided. The early uses of an antique chest or coffer included storage of fine cloth, weapons, foods and valuable items.</rdfs:comment> <rdfs:label xml:lang="en">Chest</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#Coffin"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Rack"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#StoragePieceOfFurniture"/> </owl:Class> <owl:Class rdf:ID="OtherChest">

ANEXO I

- 154 -

<owl:disjointWith> <owl:Class rdf:ID="HopeChest"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="MedicineChest"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ChestOfDrawers"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="SlopChest"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="SeaChest"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Chest"/> <rdfs:label xml:lang="en">Other Chest</rdfs:label> </owl:Class> <owl:Class rdf:ID="WheeledChildConveyance"> <owl:disjointWith> <owl:Class rdf:ID="ChangingTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Cot"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ChildrenHighChair"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Playpen"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="CarryCot"/> </owl:disjointWith> <rdfs:label xml:lang="en">Wheeled child convenyance</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</owl:hasValue> <owl:onProperty> <owl:DatatypeProperty rdf:about="#hasCastors"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:hasValue> <ChildrenUse rdf:ID="ChildrenTransportUse"> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Children transport use</hasName> <rdfs:label xml:lang="en">Childrens Transport use</rdfs:label> </ChildrenUse> </owl:hasValue> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> </owl:Restriction> <owl:Class rdf:about="#ChildrenPieceOfFurniture"/>

ANEXO I

- 155 -

</owl:intersectionOf> </owl:Class> </owl:equivalentClass> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Vehicle designed for the carriage of 1 or more children and which can be pushed or steered manually.</rdfs:comment> </owl:Class> <owl:Class rdf:about="#CoffeeTable"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A coffee table is a style of long, low table which is designed to be placed in front of a couch, to support beverages (hence the name), magazines, books (especially coffee table books), and other small items to be used while sitting, such as coasters. Coffee tables are usually found in the living room or sitting room. They are available in many different variations and prices vary from style to style. Coffee tables may also incorporate cabinets for storage.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#SofaTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#DiningTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#LoungeTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#TVStand"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#HIFIStand"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#HomeStudentDesk"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#DomesticTable"/> </rdfs:subClassOf> <rdfs:label xml:lang="en">Coffee Table</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#EndTable"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#ServingTrolley"/> <owl:disjointWith> <owl:Class rdf:about="#BedsideTable"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="OtherFinish"> <owl:disjointWith> <owl:Class rdf:ID="Upholstered"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Veneer"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Finish"/> <rdfs:label xml:lang="en">Other finishes</rdfs:label> </owl:Class> <owl:Class rdf:about="#PetDoor"> <owl:disjointWith> <owl:Class rdf:about="#Trapdoor"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Door"/>

ANEXO I

- 156 -

</rdfs:subClassOf> <owl:disjointWith rdf:resource="#GardenDoor"/> <owl:disjointWith> <owl:Class rdf:about="#BypassDoor"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#LouverDoor"/> <owl:disjointWith rdf:resource="#BifoldDoor"/> <rdfs:subClassOf> <owl:Restriction> <owl:allValuesFrom> <owl:Class rdf:about="#HomeUse"/> </owl:allValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#FrenchDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#StableDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#ButterflyDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#FlushDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#RevolvingDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#UpAndOverDoor"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A pet door is an opening in a door to allow pets to enter and exit without the main door being opened.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#BarnDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#SlidingDoor"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#SwingDoor"/> <owl:disjointWith> <owl:Class rdf:about="#FalseDoor"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#BlindDoor"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="BarStool"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:hasValue rdf:resource="#RestaurantAndBarUse"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/>

ANEXO I

- 157 -

</owl:onProperty> </owl:Restriction> <owl:Class rdf:ID="Stool"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <rdfs:label xml:lang="en">Bar Stool</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A chair with high seating height intended to be used at a high table or desk like a bar, a bistro table or a counter. For up-right sitting, with legs or foot without backrest and without armrests. Barstools are a type of stool often with a foot rest which, because of their height and narrowness, are designed for seating in a bar. Sometimes barstools are in homes, usually placed at the kitchen counter or at a home bar.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:ID="Ottoman"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="GardenStool"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="StepStool"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:about="#BathScreen"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A shower screen.</rdfs:comment> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Screen"/> <owl:Restriction> <owl:hasValue> <OtherHomeUse rdf:ID="BathroomHomeUse"> <rdfs:label xml:lang="en">Bathrooms</rdfs:label> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Bathroom home use</hasName> </OtherHomeUse> </owl:hasValue> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <owl:disjointWith> <owl:Class rdf:about="#ChangingRoomPartition"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#OfficeScreen"/> <owl:disjointWith> <owl:Class rdf:about="#ExhibitionScreen"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#FireScreen"/> <owl:disjointWith> <owl:Class rdf:about="#RestroomPartition"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#OtherScreen"/> </owl:disjointWith> </owl:Class>

ANEXO I

- 158 -

<owl:Class rdf:about="#FrameTableBase"> <owl:disjointWith> <owl:Class rdf:about="#Spring"/> </owl:disjointWith> <rdfs:label xml:lang="en">Table Frame</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#CantileverFrame"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Swivel"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Rocker"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#BedBase"/> <owl:disjointWith> <owl:Class rdf:about="#Leg"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Base"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Pedestal"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="BoosterHighChair"> <rdfs:subClassOf> <owl:Class rdf:about="#ChildrenHighChair"/> </rdfs:subClassOf> <rdfs:label xml:lang="en">Booster high chair</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Booster chairs or booster high chairs raise the height of children on regular chairs so they can eat at the main dining table.</rdfs:comment> </owl:Class> <owl:Class rdf:about="#TowelRack"> <rdfs:subClassOf> <owl:Class rdf:about="#BathroomRack"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A rack for storing towels. In Spanish, "toallero".</rdfs:comment> <owl:disjointWith rdf:resource="#RobeRack"/> <rdfs:label xml:lang="en">Towel Rack</rdfs:label> </owl:Class> <owl:Class rdf:about="#KitchenRack"> <owl:disjointWith> <owl:Class rdf:about="#HatRack"/> </owl:disjointWith> <rdfs:label xml:lang="en">Kitchen Rack</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#ShoeRack"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#UmbrellaStand"/> <owl:disjointWith> <owl:Class rdf:about="#MagazineRack"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#DryingRack"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#CDDVDRack"/>

ANEXO I

- 159 -

</owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#BathroomRack"/> </owl:disjointWith> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> <owl:hasValue> <OtherHomeUse rdf:ID="KitchenHomeUse"> <rdfs:label xml:lang="en">Kitchens</rdfs:label> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Kittchen use</hasName> </OtherHomeUse> </owl:hasValue> </owl:Restriction> <owl:Class rdf:about="#DomesticRack"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="StreetBench"> <owl:disjointWith> <owl:Class rdf:ID="OtherBench"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:DatatypeProperty rdf:ID="isFixedAtFloor"/> </owl:onProperty> <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</owl:hasValue> </owl:Restriction> </rdfs:subClassOf> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:hasValue rdf:resource="#UrbanFurnitureUse"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#hasUse"/> </owl:onProperty> </owl:Restriction> <owl:Restriction> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >2</owl:minCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="hasSeat"/> </owl:onProperty> </owl:Restriction> <owl:Class rdf:ID="Bench"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <owl:disjointWith> <owl:Class rdf:ID="GardenBench"/> </owl:disjointWith>

ANEXO I

- 160 -

<owl:disjointWith> <owl:Class rdf:ID="ReligiousBench"/> </owl:disjointWith> <rdfs:label xml:lang="en">Street Bench</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="PianoBench"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ParkBench"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A public street bench set outdoors and fixed at floor.</rdfs:comment> </owl:Class> <owl:Class rdf:ID="WritingDesk"> <rdfs:subClassOf> <owl:Class rdf:about="#OfficeDesk"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="ExecutiveDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="StandingDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="ComputerDesk"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A writing desk acts as a kind of compact office. Traditionally, a writing desk is for writing letters by hand. It usually has a top that closes to hide current work, which makes the room containing it look tidy, maintains privacy, and protects the work. The closing top may contain several joints so that it can roll closed, or may simply fold closed. The writing surface (or place for lap-top) typically folds down (perhaps being the lid) or slides out, to preserve the compact size when closed. They often have small drawers or "pigeon holes".</rdfs:comment> <rdfs:label xml:lang="en">Writing Desk</rdfs:label> </owl:Class> <owl:Class rdf:about="#Swivel"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Base giratoria</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about="#Pedestal"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Rocker"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Leg"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#CantileverFrame"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#BedBase"/> <owl:disjointWith rdf:resource="#FrameTableBase"/> <owl:disjointWith> <owl:Class rdf:about="#Spring"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Base"/> </rdfs:subClassOf> <rdfs:label xml:lang="en">Swivel</rdfs:label> </owl:Class>

ANEXO I

- 161 -

<owl:Class rdf:about="#Pedestal"> <owl:disjointWith rdf:resource="#Swivel"/> <rdfs:label xml:lang="en">Pedestal</rdfs:label> <owl:disjointWith rdf:resource="#BedBase"/> <rdfs:subClassOf> <owl:Class rdf:about="#Base"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Rocker"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#CantileverFrame"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Spring"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Leg"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#FrameTableBase"/> </owl:Class> <owl:Class rdf:about="#ColectivitiesUse"> <rdfs:subClassOf> <owl:Class rdf:about="#Use"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#HomeUse"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="OtherUse"/> </owl:disjointWith> <rdfs:label xml:lang="en">Colectivities</rdfs:label> </owl:Class> <owl:Class rdf:ID="ElectricChair"> <rdfs:label xml:lang="en">Electric Chair</rdfs:label> <owl:disjointWith> <owl:Class rdf:ID="ManualWheelChair"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:ID="WheelChair"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Electric-powered wheelchair for people with disabilities.</rdfs:comment> </owl:Class> <owl:Class rdf:about="#SlopChest"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A store of clothing and personal requisites (as tobacco) carried on merchant ships for issue to the crew usually as a charge against their wages.</rdfs:comment> <rdfs:subClassOf rdf:resource="#Chest"/> <owl:disjointWith> <owl:Class rdf:about="#ChestOfDrawers"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#HopeChest"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#SeaChest"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#OtherChest"/> <owl:disjointWith>

ANEXO I

- 162 -

<owl:Class rdf:about="#MedicineChest"/> </owl:disjointWith> <rdfs:label xml:lang="en">Slop Chest</rdfs:label> </owl:Class> <owl:Class rdf:ID="TreePot"> <owl:disjointWith> <owl:Class rdf:ID="PlotPower"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#PlantContainer"/> </rdfs:subClassOf> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A treepot is any container in which trees are cultivated.</rdfs:comment> </owl:Class> <owl:Class rdf:about="#Veneer"> <rdfs:subClassOf rdf:resource="#Finish"/> <rdfs:label xml:lang="en">Veneer</rdfs:label> <owl:disjointWith> <owl:Class rdf:about="#Upholstered"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#OtherFinish"/> </owl:Class> <owl:Class rdf:about="#ConferenceTable"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A big table used for conference meetings.</rdfs:comment> <rdfs:subClassOf> <owl:Class rdf:about="#OfficeTable"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#OfficeDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#ReceptionTable"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#OtherOfficeTable"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#WritingTable"/> <owl:disjointWith> <owl:Class rdf:about="#DrawingTable"/> </owl:disjointWith> <rdfs:label xml:lang="en">Conference Table</rdfs:label> </owl:Class> <owl:Class rdf:about="#RoofRack"> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >A system used on automobiles which was designed to carry sporting goods and luggage on top of a car. They're popular among skiers, snowboarders, cyclist, and kayakers. In Spanish, "vaca".</rdfs:comment> <rdfs:label xml:lang="en">Roof Rack</rdfs:label> <rdfs:subClassOf> <owl:Class rdf:about="#Rack"/> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#BicycleRack"/> <owl:disjointWith> <owl:Class rdf:about="#DomesticRack"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:about="#LinenCupboard"> <owl:disjointWith rdf:resource="#CornerCupboard"/> <owl:disjointWith>

ANEXO I

- 163 -

<owl:Class rdf:about="#FumeCupboard"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#OtherCupboard"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Wardrobe"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#BroomCupboard"/> </owl:disjointWith> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >In Spanish, "armario ropero".</rdfs:comment> <rdfs:subClassOf> <owl:Class rdf:about="#Cupboard"/> </rdfs:subClassOf> <rdfs:label xml:lang="en">Linen Cupboard</rdfs:label> </owl:Class> <owl:Class rdf:about="#ExecutiveDesk"> <rdfs:label xml:lang="en">Executive Desk</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >An executive desk is a the central desk for a meeting between several persons.</rdfs:comment> <owl:disjointWith rdf:resource="#WritingDesk"/> <owl:disjointWith> <owl:Class rdf:about="#ComputerDesk"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#StandingDesk"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#OfficeDesk"/> </rdfs:subClassOf> </owl:Class> … <Catalogue rdf:ID="CatalogoMariner"> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Catálogo Mariner S.A.</hasName> <hasDate rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >2008</hasDate> <hasProvider> <Manufacturer rdf:ID="Mariner"> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Mariner S.A.</hasName> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Mariner S.A.</rdfs:label> </Manufacturer> </hasProvider> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Mariner S.A. Catalogue</rdfs:label> <hasProduct> <LoungeTable rdf:ID="MesaAlina_MX2200"> <hasForm rdf:resource="#SquareForm"/> <hasWidth rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >200.0</hasWidth> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Table of extensible dining room.</rdfs:comment> <hasImage rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >src/es/pfc/resources/img/MESAS/ALINA.jpg</hasImage> <hasMaterial rdf:resource="#OakWood"/>

ANEXO I

- 164 -

<hasHorizontalSurface rdf:resource="#GeneralHorizontalSurface"/> <hasPrice> <Price rdf:ID="Price_AlinaTable"> <hasDescriptionPrice rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >HighPrice</hasDescriptionPrice> <hasUnit rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >€</hasUnit> <hasValue_component rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1800</hasValue_component> </Price> </hasPrice> <hasLength rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >90.0</hasLength> <hasCommerce rdf:resource="#Sindora"/> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Mesa Alina (MX 2200)</hasName> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Alina Table</rdfs:label> <hasStyle rdf:resource="#ModernStyle"/> <hasManufacturer> <Manufacturer rdf:ID="AndreuWorld"> <hasBuyer> <Shop rdf:ID="MoblesPass-Avant_AlfafarSedavi"> <hasProvince rdf:resource="#Valencia"/> <hasAddress> <Address rdf:ID="Address_MoblesPassAvant"> <hasStreet_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >66</hasStreet_number> <hasStreet rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Avda. Albufera</hasStreet> <hasUrl rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >http://www.passe-avant.com/</hasUrl> <hasTelephone_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >96-318-22-77</hasTelephone_number> <hasRegion rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Valencia</hasRegion> <hasTelex_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >96-318-22-78</hasTelex_number> <hasElectronic_mail_address rdf:datatype= "http://www.w3.org/2001/XMLSchema#string" >[email protected]</hasElectronic_mail_address> <hasTown rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Alfafar</hasTown> </Address> </hasAddress> </Shop> </hasBuyer> <rdfs:comment xml:lang="es">Andreu World tiene su origen en la idea e inquietud de su fundador y presidente, Francisco Andreu Martí. Hoy en día reúne a un equipo de profesionales altamente cualificados, a partir de una premisa muy clara: diseño y calidad.</rdfs:comment> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Andreu World</rdfs:label> <hasCatalogue> <Catalogue rdf:ID="CatalogueAndreuWorld"> <hasProduct> <Chair rdf:ID="CarlotaChair"> <hasBase> <HighLeg rdf:ID="HighLeg_CarlotaChair"/> </hasBase> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

ANEXO I

- 165 -

>Carlota Chair</hasName> <hasImage rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >src/es/pfc/resources/img/SILLAS/CARLOTA_CHAIR.jpg</hasImage> <hasFootRests rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >false</hasFootRests> <hasManuallyAdjustableHeight rdf:datatype= "http://www.w3.org/2001/XMLSchema#boolean" >false</hasManuallyAdjustableHeight> <hasManufacturer rdf:resource="#AndreuWorld"/> <hasElectricallyAdjustableHeight rdf:datatype= "http://www.w3.org/2001/XMLSchema#boolean" >false</hasElectricallyAdjustableHeight> <isUpholstered rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</isUpholstered> <hasPossibleFinishing rdf:resource="#Fabric"/> <hasUpholstered rdf:resource="#Fabric"/> <isAdjustable rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >false</isAdjustable> <hasPrice> <Price rdf:ID="Price_CarlotaChair"> <hasValue_component rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >300</hasValue_component> <hasUnit rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >€</hasUnit> </Price> </hasPrice> <hasHeight rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >78.0</hasHeight> <hasRecliningSystem rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >false</hasRecliningSystem> <hasSeat> <SeatPart rdf:ID="SeatPart_CarlotaChair"/> </hasSeat> <hasNumberOfLegs rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >4</hasNumberOfLegs> <hasLegs rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >true</hasLegs> <hasLength rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >55.0</hasLength> <hasMaterial> <Wood rdf:ID="BeechWood"> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Beech Wood</hasName> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Beech Wood</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >"Madera de Haya", "haya", "madera", "wood"</rdfs:comment> </Wood> </hasMaterial> <hasStyle rdf:resource="#ModernStyle"/> <hasCastors rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >false</hasCastors> <hasPossibleColour rdf:resource="#Gray"/> <hasPossibleColour rdf:resource="#Brown"/> <hasCommerce rdf:resource="#CosinCosin"/> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >The collection of chairs, sofas, armchairs and stools Carlotta is characterized by its friendly and rounded forms. It comes in solid wood but has the chair and armchair versions are also available in solid wood oak, and incorporates two different types of backup: upholstered or natural grid.

ANEXO I

- 166 -

Carlotta SI 0917 model has a structure of beechwood with woven seat and back.</rdfs:comment> <hasWidth rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >52.0</hasWidth> <isStackable rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean" >false</isStackable> <hasBackrest> <Backrest rdf:ID="Backrest_CarlotaChair"/> </hasBackrest> <hasCommerce rdf:resource="#MoblesPass-Avant_AlfafarSedavi"/> </Chair> </hasProduct> <hasProduct> <Chair rdf:ID="LinealChair"> <hasCommerce> <Commerce rdf:ID="MueblesMartinez"> <hasProvince rdf:resource="#Alicante"/> <hasAddress> <Address rdf:ID="Address_MueblesMartinez"> <hasStreet_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >7</hasStreet_number> <hasPostal_code rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >03720</hasPostal_code> <hasElectronic_mail_address xml:lang="en" ></hasElectronic_mail_address> <hasUrl rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >www.martinezmuebles.com</hasUrl> <hasRegion rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Alicante</hasRegion> <hasTown rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >BENISSA</hasTown> <hasStreet rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Avda. País Valencià</hasStreet> </Address> </hasAddress> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Muebles Martinez</rdfs:label> </Commerce> </hasCommerce> <hasCommerce> <Shop rdf:ID="Mobles_Pass-Avant_Valencia"> <hasProvince rdf:resource="#Valencia"/> <hasAddress> <Address rdf:ID="Address_MoblesPass-Avant_Valencia"> <hasRegion rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Valencia</hasRegion> <hasTelephone_number rdf:datatype= "http://www.w3.org/2001/XMLSchema#string" >963 61 37 62</hasTelephone_number> <hasTelex_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >96 362 00 34</hasTelex_number> <hasTown rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Valencia</hasTown> <hasStreet_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >32-34</hasStreet_number> <hasPostal_code rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >46021</hasPostal_code> <hasCountry rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Spain</hasCountry> <hasElectronic_mail_address rdf:datatype= "http://www.w3.org/2001/XMLSchema#string"

ANEXO I

- 167 -

>[email protected]</hasElectronic_mail_address> <hasStreet rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Avda. Aragón</hasStreet> </Address> </hasAddress> </Shop> </hasCommerce> <hasBase> <CantileverFrame rdf:ID="CantileverFrame_LiealChair"> <hasMaterial rdf:resource="#Iron"/> <hasPossibleFinishing> <OtherFinish rdf:ID="Chrome"> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Chrome</rdfs:label> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >"Cromado"</rdfs:comment> </OtherFinish> </hasPossibleFinishing> </CantileverFrame> </hasBase> <hasPossibleFinishing rdf:resource="#Chrome"/> <hasSeat> <SeatPart rdf:ID="SeatPart_LinealChair"> <hasMaterial rdf:resource="#OakWood"/> <hasPossibleColour rdf:resource="#White"/> <hasPossibleFinishing rdf:resource="#Lacquered"/> </SeatPart> </hasSeat> <hasLength rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >52.5</hasLength> <hasCommerce rdf:resource="#Sindora"/> <hasBackrest> <Backrest rdf:ID="Backrest_LinealChair"> <hasPossibleFinishing rdf:resource="#Lacquered"/> <hasPossibleColour rdf:resource="#White"/> <hasMaterial rdf:resource="#OakWood"/> </Backrest> </hasBackrest> <hasWidth rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >51.5</hasWidth> <hasManufacturer rdf:resource="#AndreuWorld"/> <hasCommerce rdf:resource="#MueblesGozalbo"/> <hasStyle rdf:resource="#ModernStyle"/> <hasPrice> <Price rdf:ID="Price_LinealChair"> <hasUnit rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >€</hasUnit> <hasDescriptionPrice rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >MiddlePrice</hasDescriptionPrice> <hasValue_component rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >200</hasValue_component> </Price> </hasPrice> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Chair Lineal</rdfs:label> <hasMaterial rdf:resource="#Iron"/> <hasCommerce rdf:resource="#CosinCosin"/> <hasImage rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >src/es/pfc/resources/img/SILLAS/LINEAL_CHAIR.jpg</hasImage> <hasCommerce>

ANEXO I

- 168 -

<Commerce rdf:ID="DivanoPielSegorbe"> <hasAddress> <Address rdf:ID="Address_Divano"> <hasTelex_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >96471202</hasTelex_number> <hasUrl rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >http://www.divanopiel.com/</hasUrl> <hasStreet rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Avda. España</hasStreet> <hasElectronic_mail_address rdf:datatype= "http://www.w3.org/2001/XMLSchema#string" >[email protected] <[email protected]></hasElectronic_mail_address> <hasPostal_code rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >12400</hasPostal_code> <hasTelephone_number rdf:datatype= "http://www.w3.org/2001/XMLSchema#string" >964712699</hasTelephone_number> <hasRegion rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Castellón</hasRegion> <hasTown rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >SEGORBE</hasTown> <hasStreet_number rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >139</hasStreet_number> <hasCountry rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Spain</hasCountry> </Address> </hasAddress> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Divano Piel Segorbe</rdfs:label> <hasProvince rdf:resource="#Castellon"/> </Commerce> </hasCommerce> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Structure of iron rod chrome, trim and back panel of oak</rdfs:comment> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Lineal Chair (SI 0584)</hasName> <hasHeight rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >51.5</hasHeight> <hasPossibleColour rdf:resource="#White"/> </Chair> </hasProduct> <hasProduct> <Chair rdf:ID="ManilaChair"> <hasSeat> <SeatPart rdf:ID="SeatPart_ManilaChair"> <hasPossibleFinishing rdf:resource="#Leather"/> </SeatPart> </hasSeat> <hasPossibleFinishing rdf:resource="#Leather"/> <hasBase> <HighLeg rdf:ID="HighLeg_ManilaChair"> <hasMaterial rdf:resource="#BeechWood"/> <hasPossibleColour rdf:resource="#Black"/> </HighLeg> </hasBase> <hasImage rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >src/es/pfc/resources/img/SILLAS/MANILA_CHAIR.jpg</hasImage> <hasCommerce rdf:resource="#MoblesPass-Avant_AlfafarSedavi"/> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

ANEXO I

- 169 -

>Manila Chair</rdfs:label> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Manila Chair (SO 2017)</hasName> <hasHeight rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >80.0</hasHeight> <hasArmrests> <Armrest rdf:ID="Armrests_ManilaChair"/> </hasArmrests> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Structure of beech wood, trim and back upholstered</rdfs:comment> <hasNumberOfLegs rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >4</hasNumberOfLegs> <hasStyle rdf:resource="#ModernStyle"/> <hasSize> <Size rdf:ID="MiddleSize"> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Middle</hasName> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Middle</rdfs:label> </Size> </hasSize> <hasWidth rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >58.5</hasWidth> <hasPossibleColour rdf:resource="#Black"/> <hasManufacturer rdf:resource="#AndreuWorld"/> <hasPrice> <Price rdf:ID="Price_ManilaChair"> <hasUnit rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >€</hasUnit> <hasValue_component rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >300</hasValue_component> <hasDescriptionPrice rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >MiddlePrice</hasDescriptionPrice> </Price> </hasPrice> <hasLength rdf:datatype="http://www.w3.org/2001/XMLSchema#float" >54.0</hasLength> <hasCommerce rdf:resource="#CosinCosin"/> <hasMaterial rdf:resource="#BeechWood"/> <hasBackrest> <Backrest rdf:ID="Backrest_ManilaChair"> <hasPossibleFinishing rdf:resource="#Leather"/> </Backrest> </hasBackrest> </Chair> </hasProduct> <hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Andreu World Catalog</hasName> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Andreu World Catalog</rdfs:label> <hasProvider rdf:resource="#AndreuWorld"/> </Catalogue> </hasCatalogue> …

ANEXO II

- 170 -

ANEXO II

- 171 -

Anexo II: funStep-Data catalog.xml <?xml version="1.0" encoding="utf-8"?> <p28doc:iso_10303_28 version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cnf="urn:oid:1.0.10303.28.2.1.2" xmlns:p28doc="urn:oid:1.0.10303.28.2.1.3" xsi:schemaLocation="urn:oid:1.0.10303.28.2.1.1 exp.xsd urn:oid:1.0.10303.28.2.1.3 p28.xsd urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm CC1_subset_Corrected_v2.xsd"> <p28doc:express id="AP236_Implementation_Subset_LF_arm" schema_name="AP236_Implementation_Subset_LF_arm" schemaLocation="./AP236_Implementation_Subset_LF_arm_v2.exp" xsi:nil="true"/> <cnf:configuration id="conf" schema="AP236_Implementation_Subset_LF_arm" configurationLocation="./config.xml" xsi:nil="true"/> <exp:uos id="data01" xmlns:cadainlofo="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm" xmlns:exp="urn:oid:1.0.10303.28.2.1.1" xsi:schemaLocation="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm CC1_subset_Corrected_v2.xsd" express="AP236_Implementation_Subset_LF_arm" configuration="conf" xsi:type="cadainlofo:uos">  <cadainlofo:Organization id="o_0001"> <id>Furn</id> <name>The FurniBest</name> </cadainlofo:Organization> <cadainlofo:Address id="a_0001"> <street_number>25</street_number> <street>Anystreet</street> <town>Anytown</town> <electronic_mail_address>[email protected]</electronic_mail_address> </cadainlofo:Address> <cadainlofo:Address_assignment id="aa_0001"> <assigned_address ref="a_0001"/> <located_person_organizations> <cadainlofo:Organization ref="o_0001"/> </located_person_organizations> </cadainlofo:Address_assignment> <cadainlofo:Person id="p_0001"> <last_name>Doe</last_name> <first_name>John</first_name> </cadainlofo:Person> <cadainlofo:Person_in_organization id="pio_0001"> <concerned_person ref="p_0001"/> <containing_organization ref="o_0001"/> <role>Employee</role> </cadainlofo:Person_in_organization> <cadainlofo:Organization_or_person_in_organization_assignment id="id_oopioa_0"> <assigned_entity> <cadainlofo:Organization ref="o_0001"/> </assigned_entity> <role>Catalog</role> <items> <cadainlofo:Product_class ref="pc_0001"/> </items> </cadainlofo:Organization_or_person_in_organization_assignment>

ANEXO II

- 172 -

 <cadainlofo:Product_class id="pc_0001"> <id>FurniB-C001</id> <name>Catalog C 001</name> <level_type>catalog</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0002"> <id>Legs</id> <name>Legs</name> <level_type>line</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0003"> <id>Boards</id> <name>Boards</name> <level_type>line</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0004"> <id>Tables</id> <name>Tables</name> <level_type>line</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0005"> <id>Chairs</id> <name>Chairs</name> <level_type>line</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0006"> <id>Legs_1</id> <name>Legs_1</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0007"> <id>Legs_2</id> <name>Legs_2</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0008"> <id>Legs_3</id> <name>Legs_3</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0009"> <id>Board_1</id> <name>Board_1</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0010"> <id>Board_2</id> <name>Board_2</name> <level_type>product</level_type>

ANEXO II

- 173 -

</cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0011"> <id>Table_1</id> <name>Table_1</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0012"> <id>Table_2</id> <name>Table_2</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0013"> <id>Table_3</id> <name>Table_3</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0014"> <id>Chair_1</id> <name>Chair_1</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0015"> <id>Chair_2</id> <name>Chair_2</name> <level_type>product</level_type> </cadainlofo:Product_class>  <cadainlofo:Product_class_relationship id="pcr_0001"> <relating ref="pc_0001"/> <related ref="pc_0002"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0002"> <relating ref="pc_0001"/> <related ref="pc_0003"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0003"> <relating ref="pc_0001"/> <related ref="pc_0004"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0004"> <relating ref="pc_0001"/> <related ref="pc_0005"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0005"> <relating ref="pc_0002"/>

ANEXO II

- 174 -

<related ref="pc_0006"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0006"> <relating ref="pc_0002"/> <related ref="pc_0007"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0007"> <relating ref="pc_0002"/> <related ref="pc_0008"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0008"> <relating ref="pc_0003"/> <related ref="pc_0009"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0009"> <relating ref="pc_0003"/> <related ref="pc_0010"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0010"> <relating ref="pc_0004"/> <related ref="pc_0011"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0011"> <relating ref="pc_0004"/> <related ref="pc_0012"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0012"> <relating ref="pc_0004"/> <related ref="pc_0013"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0013"> <relating ref="pc_0005"/> <related ref="pc_0014"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0014"> <relating ref="pc_0005"/> <related ref="pc_0015"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0015"> <relating ref="pc_0011"/>

ANEXO II

- 175 -

<related ref="pc_0009"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0016"> <relating ref="pc_0011"/> <related ref="pc_0006"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0017"> <relating ref="pc_0012"/> <related ref="pc_0009"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0018"> <relating ref="pc_0012"/> <related ref="pc_0007"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0019"> <relating ref="pc_0013"/> <related ref="pc_0010"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0020"> <relating ref="pc_0013"/> <related ref="pc_0008"/> <relation_type>composition</relation_type> </cadainlofo:Product_class_relationship>  <cadainlofo:Specification_category id="sc_0001"> <id>colour</id> <description>Available catalog colours</description> <implicit_exclusive_condition>true</implicit_exclusive_condition> </cadainlofo:Specification_category> <cadainlofo:Specification_category id="sc_0002"> <id>material</id> <description>Available catalog materials</description> <implicit_exclusive_condition>true</implicit_exclusive_condition> </cadainlofo:Specification_category> <cadainlofo:Specification_category id="sc_0003"> <id>wheels</id> <description>determines if the product has wheels</description> <implicit_exclusive_condition>true</implicit_exclusive_condition> </cadainlofo:Specification_category> <cadainlofo:Specification_category id="sc_0004"> <id>fabrics</id> <description>Available catalog fabrics for chairs</description> <implicit_exclusive_condition>true</implicit_exclusive_condition> </cadainlofo:Specification_category>

ANEXO II

- 176 -

 <cadainlofo:Class_category_association id="cca_0001"> <associated_product_class ref="pc_0001"/> <mandatory>true</mandatory> <associated_category ref="sc_0001"/> </cadainlofo:Class_category_association> <cadainlofo:Class_category_association id="cca_0002"> <associated_product_class ref="pc_0001"/> <mandatory>true</mandatory> <associated_category ref="sc_0002"/> </cadainlofo:Class_category_association> <cadainlofo:Class_category_association id="cca_0003"> <associated_product_class ref="pc_0001"/> <mandatory>true</mandatory> <associated_category ref="sc_0003"/> </cadainlofo:Class_category_association> <cadainlofo:Class_category_association id="cca_0004"> <associated_product_class ref="pc_0001"/> <mandatory>true</mandatory> <associated_category ref="sc_0004"/> </cadainlofo:Class_category_association>  <cadainlofo:Specification id="s_0001"> <id>G</id> <name>Green</name> <category ref="sc_0001"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0002"> <id>B</id> <name>Blue</name> <category ref="sc_0002"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0003"> <id>Y</id> <name>Yellow</name> <category ref="sc_0001"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0004"> <id>R</id> <name>Red</name> <category ref="sc_0001"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0005"> <id>O</id> <name>Orange</name> <category ref="sc_0001"/>

ANEXO II

- 177 -

<package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0006"> <id>Wh</id> <name>White</name> <category ref="sc_0001"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0007"> <id>Bl</id> <name>Black</name> <category ref="sc_0001"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0008"> <id>I</id> <name>Iron</name> <category ref="sc_0002"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0009"> <id>Wo</id> <name>Wood</name> <category ref="sc_0002"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0010"> <id>Pl</id> <name>Plastic</name> <category ref="sc_0002"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0011"> <id>ww</id> <name>with wheels</name> <category ref="sc_0003"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0012"> <id>wow</id> <name>without wheels</name> <category ref="sc_0003"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0013"> <id>B01</id> <name>Boudeaux_01</name> <category ref="sc_0004"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0014">

ANEXO II

- 178 -

<id>PX</id> <name>Pistachio_X</name> <category ref="sc_0004"/> <package>false</package> </cadainlofo:Specification> <cadainlofo:Specification id="s_0015"> <id>OFA</id> <name>Old_Fashion_Aubergine</name> <category ref="sc_0004"/> <package>false</package> </cadainlofo:Specification>   <cadainlofo:Product_specification id="ps_0001"> <id>legs_1a</id> <name>legs_1a</name> <description>this is a configured leg</description> <item_context ref="pc_0006"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0002"> <id>legs_1c</id> <name>legs_1c</name> <description>this is a configured leg</description> <item_context ref="pc_0006"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0003"> <id>legs_1c</id> <name>legs_1c</name> <description>this is a configured leg</description> <item_context ref="pc_0006"/> <defining_specifications>  <cadainlofo:Specification ref="s_0003"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0004"> <id>legs_1d</id>

ANEXO II

- 179 -

<name>legs_1d</name> <description>this is a configured leg</description> <item_context ref="pc_0006"/> <defining_specifications>  <cadainlofo:Specification ref="s_0004"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0005"> <id>legs_2a</id> <name>legs_2a</name> <description>this is a configured leg</description> <item_context ref="pc_0007"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0006"> <id>legs_2b</id> <name>legs_2b</name> <description>this is a configured leg</description> <item_context ref="pc_0007"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0007"> <id>legs_2c</id> <name>legs_2c</name> <description>this is a configured leg</description> <item_context ref="pc_0007"/> <defining_specifications>  <cadainlofo:Specification ref="s_0003"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0008"> <id>legs_2d</id> <name>legs_2d</name> <description>this is a configured leg</description> <item_context ref="pc_0007"/> <defining_specifications>

ANEXO II

- 180 -

 <cadainlofo:Specification ref="s_0004"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0009"> <id>legs_3a</id> <name>legs_3a</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0010"> <id>legs_3b</id> <name>legs_3b</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0005"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0011"> <id>legs_3c</id> <name>legs_3c</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0012"> <id>legs_3d</id> <name>legs_3d</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0010"/>

ANEXO II

- 181 -

</defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0013"> <id>legs_3e</id> <name>legs_3e</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0005"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0014"> <id>legs_3f</id> <name>legs_3f</name> <description>this is a configured leg</description> <item_context ref="pc_0008"/> <defining_specifications>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0015"> <id>Board_1a</id> <name>Board_1a</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0016"> <id>Board_1b</id> <name>Board_1b</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification> 

ANEXO II

- 182 -

<cadainlofo:Product_specification id="ps_0017"> <id>Board_1c</id> <name>Board_1c</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0003"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0018"> <id>Board_1d</id> <name>Board_1d</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0004"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0019"> <id>Board_1e</id> <name>Board_1e</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0020"> <id>Board_1f</id> <name>Board_1f</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0021"> <id>Board_1g</id> <name>Board_1g</name> <description>this is a configured board</description>

ANEXO II

- 183 -

<item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0003"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0022"> <id>Board_1h</id> <name>Board_1h</name> <description>this is a configured board</description> <item_context ref="pc_0009"/> <defining_specifications>  <cadainlofo:Specification ref="s_0004"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0023"> <id>Board_2a</id> <name>Board_2a</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0024"> <id>Board_2b</id> <name>Board_2b</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0025"> <id>Board_2c</id> <name>Board_2c</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0005"/>

ANEXO II

- 184 -

 <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0026"> <id>Board_2d</id> <name>Board_2d</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0027"> <id>Board_2e</id> <name>Board_2e</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0028"> <id>Board_2f</id> <name>Board_2f</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0029"> <id>Board_2g</id> <name>Board_2g</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0005"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>

ANEXO II

- 185 -

 <cadainlofo:Product_specification id="ps_0030"> <id>Board_2h</id> <name>Board_2h</name> <description>this is a configured board</description> <item_context ref="pc_0010"/> <defining_specifications>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0031"> <id>Table_1a</id> <name>Table_1a</name> <item_context ref="pc_0011"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0008"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0032"> <id>Table_2a</id> <name>Table_2a</name> <item_context ref="pc_0012"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0009"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0033"> <id>Table_3a</id> <name>Table_3a</name> <item_context ref="pc_0013"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0002"/>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0009"/> 

ANEXO II

- 186 -

<cadainlofo:Specification ref="s_0010"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0034"> <id>Chair_1a</id> <name>Chair_1a</name> <item_context ref="pc_0014"/> <defining_specifications>  <cadainlofo:Specification ref="s_0001"/>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0005"/>  <cadainlofo:Specification ref="s_0004"/>  <cadainlofo:Specification ref="s_0010"/>  <cadainlofo:Specification ref="s_0011"/>  <cadainlofo:Specification ref="s_0012"/>  <cadainlofo:Specification ref="s_0013"/>  <cadainlofo:Specification ref="s_0014"/> </defining_specifications> </cadainlofo:Product_specification>  <cadainlofo:Product_specification id="ps_0035"> <id>Chair_2a</id> <name>Chair_2a</name> <description>this is a possible group configuration</description> <item_context ref="pc_0015"/> <defining_specifications>  <cadainlofo:Specification ref="s_0007"/>  <cadainlofo:Specification ref="s_0006"/>  <cadainlofo:Specification ref="s_0009"/>  <cadainlofo:Specification ref="s_0012"/>  <cadainlofo:Specification ref="s_0013"/>  <cadainlofo:Specification ref="s_0015"/> </defining_specifications> </cadainlofo:Product_specification> </exp:uos> </p28doc:iso_10303_28>

ANEXO III

- 187 -

Anexo III: Properties.xml <?xml version="1.0" encoding="utf-8"?> <p28doc:iso_10303_28 version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cnf="urn:oid:1.0.10303.28.2.1.2" xmlns:p28doc="urn:oid:1.0.10303.28.2.1.3" xsi:schemaLocation="urn:oid:1.0.10303.28.2.1.1 exp.xsd urn:oid:1.0.10303.28.2.1.3 p28.xsd urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm CC1_subset_Corrected_v2.xsd"> <p28doc:express id="AP236_Implementation_Subset_LF_arm" schema_name="AP236_Implementation_Subset_LF_arm" schemaLocation="./AP236_Implementation_Subset_LF_arm_v2.exp" xsi:nil="true"/> <cnf:configuration id="conf" schema="AP236_Implementation_Subset_LF_arm" configurationLocation="./config.xml" xsi:nil="true"/> <exp:uos id="data01" xmlns:cadainlofo="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm" xmlns:exp="urn:oid:1.0.10303.28.2.1.1" xsi:schemaLocation="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm CC1_subset_Corrected_v2.xsd" express="AP236_Implementation_Subset_LF_arm" configuration="conf" xsi:type="cadainlofo:uos">  <cadainlofo:Product_class id="pc_0005"> <id>Chairs</id> <name>Chairs</name> <level_type>line</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0014"> <id>Chair_1</id> <name>Chair_1</name> <level_type>product</level_type> </cadainlofo:Product_class> <cadainlofo:Product_class id="pc_0015"> <id>Chair_2</id> <name>Chair_2</name> <level_type>product</level_type> </cadainlofo:Product_class>  <cadainlofo:Product_class_relationship id="pcr_0013"> <relating ref="pc_0005"/> <related ref="pc_0014"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship> <cadainlofo:Product_class_relationship id="pcr_0014"> <relating ref="pc_0005"/> <related ref="pc_0015"/> <relation_type>hierarchy</relation_type> </cadainlofo:Product_class_relationship>   <cadainlofo:Applied_independent_property id="aip_0001"> <name>ergonomic</name> <described_element>

ANEXO III

- 188 -

<cadainlofo:Product_class ref="pc_0014"/> </described_element> <base_independent_property ref="ip_0001"/> </cadainlofo:Applied_independent_property> <cadainlofo:Independent_property id="ip_0001"> <id>ergonomy</id> <property_type>ergonomic</property_type> </cadainlofo:Independent_property> <cadainlofo:Applied_independent_property id="aip_0002"> <name>cheap and good</name> <described_element> <cadainlofo:Product_class ref="pc_0014"/> </described_element> <base_independent_property ref="ip_0002"/> </cadainlofo:Applied_independent_property> <cadainlofo:Independent_property id="ip_0002"> <id>slogan</id> <property_type>slogan</property_type> </cadainlofo:Independent_property>  <cadainlofo:Assigned_property id="ap_0001"> <name>price</name> <described_element> <cadainlofo:Product_class ref="pc_0014"/> </described_element> </cadainlofo:Assigned_property> <cadainlofo:Property_representation id="pr_0001"> <property ref="ap_0001"/> <rep ref="r_0001"/> </cadainlofo:Property_representation> <cadainlofo:Assigned_property id="ap_0002"> <name>slogan</name> <described_element> <cadainlofo:Product_class ref="pc_0014"/> </described_element> </cadainlofo:Assigned_property> <cadainlofo:Property_representation id="pr_0002"> <property ref="ap_0002"/> <rep ref="r_0002"/> </cadainlofo:Property_representation>  <cadainlofo:Representation id="r_0001"> <context_of_items ref="rc_0001"/> <items ref="niwu_0001"/> </cadainlofo:Representation> <cadainlofo:Representation_context id="rc_0001"> <id>price in Spain</id> <kind>price</kind> </cadainlofo:Representation_context>

ANEXO III

- 189 -

<cadainlofo:Numerical_item_with_unit id="niwu_0001"> <unit ref="u_0001"/> <value_component>55</value_component> </cadainlofo:Numerical_item_with_unit> <cadainlofo:Unit id="u_0001"> <name>euros</name> <si_unit>false</si_unit> </cadainlofo:Unit> <cadainlofo:Representation id="r_0002"> <context_of_items ref="rc_0002"/> <items ref="sri_0001"/> </cadainlofo:Representation> <cadainlofo:Representation_context id="rc_0002"> <id>slogan in UK</id> <kind>slogan</kind> </cadainlofo:Representation_context> <cadainlofo:String_representation_item id="sri_0001"> <string_value>Pure London fashion</string_value> </cadainlofo:String_representation_item> </exp:uos> </p28doc:iso_10303_28>

Documents

Modelo ontologico de muebles