desarrollo de una ontología y de un sistema de recuperación de la
Anuncio
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
A mis queridos padres y hermanos
por el tiempo y los momentos que no pude pasar con ellos.
II
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.
III
IV
Í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 ‐ V
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. 6.2. CONCLUSIONES ............................................................................................ ‐ 139 ‐ TRABAJO FUTURO ........................................................................................ ‐ 141 ‐ BIBLIOGRAFÍA ............................................................................ ­ 143 ­ ANEXOS ......................................................................................... ­ 145 ­ VI
Í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 VII
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 - VIII
Í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 IX
X
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.
XI
CAPITULO 1 - INTRODUCCIÓN
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
-2-
CAPITULO 1 - INTRODUCCIÓN
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
telemáticamente.
común
para
el
intercambio
de
información
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
-3-
CAPITULO 1 - INTRODUCCIÓN
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 10303236), 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.
-4-
CAPITULO 1 - INTRODUCCIÓN
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.
-5-
CAPITULO 2 – ESTADO DEL ARTE
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.
-6-
CAPITULO 2 – ESTADO DEL ARTE
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.
-7-
CAPITULO 2 – ESTADO DEL ARTE
Figura 2.1 Componentes de la interoperabilidad en una empresa
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.
-8-
CAPITULO 2 – ESTADO DEL ARTE
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.
-9-
CAPITULO 2 – ESTADO DEL ARTE
2.2 FunStep El proyecto FunStep 2.2.1.
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.
- 10 -
CAPITULO 2 – ESTADO DEL ARTE
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.
El estándar ISO funStep 2.2.2.
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
- 11 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 12 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 13 -
CAPITULO 2 – ESTADO DEL ARTE
Figura 2.3 Captura del Cadef enlazando productos a la ontología
- 14 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 15 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 16 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 17 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 18 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 19 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 20 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 21 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 22 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 23 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 24 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 25 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 26 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 27 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 28 -
CAPITULO 2 – ESTADO DEL ARTE
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).
- 29 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 30 -
CAPITULO 2 – ESTADO DEL ARTE
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).
- 31 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 32 -
CAPITULO 2 – ESTADO DEL ARTE
adicional sobre el recurso principal. P.e.,
http://www.vocabulario.es/aparatos </rdfs:seeAlso>
<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
- 33 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 34 -
CAPITULO 2 – ESTADO DEL ARTE
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:
- 35 -
CAPITULO 2 – ESTADO DEL ARTE
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
- 36 -
CAPITULO 2 – ESTADO DEL ARTE
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.
Figura 2.11 Actividades del ciclo de vida del desarrollo de una ontología
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:
- 37 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 38 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 39 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 40 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 41 -
CAPITULO 2 – ESTADO DEL ARTE
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).
- 42 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 43 -
CAPITULO 2 – ESTADO DEL ARTE
Jena (Jena, 2007) es una colección de herramientas desarrollado por HewlettPackard 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.
- 44 -
CAPITULO 2 – ESTADO DEL ARTE
Figura 2.15 Arquitectura de un Sistema Terminológico (Horrocks, 2001).
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.
- 45 -
CAPITULO 2 – ESTADO DEL ARTE
Lenguajes de consulta 2.3.9.
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
- 46 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 47 -
CAPITULO 2 – ESTADO DEL ARTE
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.
- 48 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 49 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
Definición de recursos 3.1.1.
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).
Recursos humanos 3.1.1.1
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.
- 50 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
Recursos del entorno 3.1.1.2
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:
- 51 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
- 52 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 53 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
Figura 3.1 Descomposición del proyecto en tareas
- 54 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
Puesta al día bibliográfica
Análisis y desarrollo de la ontología
Análisis del sistema
Diseño del sistema
Implementación
Pruebas del sistema
Completar la memoria
Total
Duración estimada
240 horas
260 horas
80 horas
8 horas
100 horas
20 horas
160 horas
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
Director del proyecto
Codirectora del proyecto
Jefe de Proyecto
Analista/Programador
Total
Nombre
Javier Samper
Mª José Núñez
Miguel Ángel Abián
Mouna Ziouziou
Horas
32
20
96
872
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)
- 55 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 56 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
Figura 3.2 Diagrama de Gantt
- 57 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 58 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
Director de Proyecto
Codirector
Jefe de Proyecto
Analista/Programador
Total
Horas
32
20
96
872
1020
Coste por hora
80 €
70 €
60 €
40 €
42,35 €
Total
2.560 €
1.400 €
5.760 €
34.880 €
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.
- 59 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
PC portátil Intel Pentium Centrino
PC portátil Intel Pentium Core Duo
MS Office 2007
Material de imprenta y material fungible
Total
Coste
1.000€
1.000€
100€
50 €
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.
- 60 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
- 61 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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 (1050)
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).
- 62 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 63 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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.
- 64 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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
RELY
DATA
CPLX
TIME
STOR
PVOL
ACAP
AEXP
PCAP
LTEX
TOOL
SCED
Valor
Nominal
Muy alto
Alto
Nominal
Alto
Alto
Nominal
Bajo
Alto
Bajo
Alto
Nominal
Valor Multiplicativo
1
1.30
1.15
1
1.21
1.15
1
1.13
0.86
1.15
0.91
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
- 65 -
CAPITULO 3 – METODOLOGÍA Y PLAN DE TRABAJO
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 €
- 66 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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).
- 67 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 68 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 69 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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)
2)
3)
4)
Información de datos de catalogación.
Representación de la forma del producto.
Información parametrizada de datos de catalogación.
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
- 70 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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)
Figura 4.3 Asignación de propiedades
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.
- 71 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 72 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Figura 4.5 Diagrama de Product_class y sus relaciones
- 73 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 74 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 75 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 76 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
Adquisición de Conocimientos 4.2.3.
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.
- 77 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 78 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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:
- 79 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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: OWLLite, 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.
- 80 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
ii.
Propiedades objeto son usadas para relacionar un recurso a
otro recurso.
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.
- 81 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 82 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 83 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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).
- 84 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Figura 4.10 Diferentes niveles de la taxonomía de muebles
- 85 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 86 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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)
- 87 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 88 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 89 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
3
El cuantificador universal (), que se puede leer como sólo
En OWL se expresa como restricción “someValuesFrom”
- 90 -
CAPITULO 4 – PROCESO DE INGENIERÍA
(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”
- 91 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 92 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 93 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 94 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 95 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 96 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 97 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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:
- 98 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Figura 4.18 Caso de uso Buscar Muebles detallado.
Figura 4.19Caso de uso Buscar Composiciones detallado.
- 99 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
1.- El usuario accede a la aplicación
y desea buscar un producto.
2.- El usuario selecciona el tipo de
producto que desea buscar.
Sistema
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
- 100 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Secuencia típica de eventos:
Actor
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.
Sistema
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
1.- El usuario selecciona un producto
de la lista para obtener detalles.
Sistema
2.- Genera y ejecuta la consulta
correspondiente.
3.-Muestra la información del
producto en el interfaz de usuario.
- 101 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 102 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Figura 4.21 Diagrama de Actividad – Realizar Búsqueda
- 103 -
CAPITULO 4 – PROCESO DE INGENIERÍA
Figura 4.22 Diagrama de Actividad – Obtener detalles
- 104 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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”.
- 105 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 106 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 107 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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).
- 108 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 109 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 110 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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.
- 111 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 112 -
CAPITULO 4 – PROCESO DE INGENIERÍA
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
- 113 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
- 114 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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
- 115 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 116 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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"); } - 117 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
modelOnt=ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_M
EM_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
- 118 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 119 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 120 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 121 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 122 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 123 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 124 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 125 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.3 Ejemplo de búsqueda de muebles de un Fabricante
- 126 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.4 Ejemplo de búsqueda de Conjuntos de salón
- 127 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.5 Ejemplo de búsqueda de Composiciones con camas
- 128 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.6 Ejemplo de búsqueda de camas individuales con cabecero
- 129 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.7 Ejemplo de búsqueda de Sillas modenas en Valencia ciudad
- 130 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.8 Ejemplo de búsqueda de Sillas con un rango de precio
- 131 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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.
- 132 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.10 Obtener detalles del producto “Bedroom Syros 2”
Figura 5.11 Obtener detalles del producto “Diez4 Single Bed”
- 133 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.12 Obtener detalles del producto “Carlotta Chair”
Figura 5.13 Obtener detalles del producto “Dubai Chair”
- 134 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
Figura 5.14 Obtener detalles del producto “Javea Table 031”
- 135 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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
- 136 -
CAPITULO 5 – IMPLEMENTACIÓN Y PRUEBAS
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
- 137 -
CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO
- 138 -
CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO
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.
- 139 -
CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO
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.
- 140 -
CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO
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.
- 141 -
CAPITULO 6 – CONCLUSIONES Y TRABAJO FUTURO
Figura 6.1 Nueva implantación del Cadef (Versión beta).
- 142 -
BIBLIOGRAFÍA
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
- 143 -
BIBLIOGRAFÍA
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ías101: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
Computational Foundations. Ed Brooks Cole Publishing Co. 132-168. USA.
and
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).
- 144 -
ANEXO I
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"?>
<!-- Cabecera -->
<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"/>
- 145 -
ANEXO I
</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">
- 146 -
ANEXO I
<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>
- 147 -
ANEXO I
<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>
- 148 -
ANEXO I
<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
- 149 -
ANEXO I
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"/>
- 150 -
ANEXO I
</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>
- 151 -
ANEXO I
<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>
- 152 -
ANEXO I
<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">
- 153 -
ANEXO I
<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"/>
- 154 -
ANEXO I
</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"/>
- 155 -
ANEXO I
</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"/>
- 156 -
ANEXO I
</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>
- 157 -
ANEXO I
<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"/>
- 158 -
ANEXO I
</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>
- 159 -
ANEXO I
<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>
- 160 -
ANEXO I
<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>
- 161 -
ANEXO I
<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>
- 162 -
ANEXO I
<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"/>
- 163 -
ANEXO I
<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"
- 164 -
ANEXO I
>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.
- 165 -
ANEXO I
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"
- 166 -
ANEXO I
>[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>
- 167 -
ANEXO I
<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]
&lt;[email protected]&gt;</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"
- 168 -
ANEXO I
>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>
…
- 169 -
ANEXO II
- 170 -
ANEXO II
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:iso1030328: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">
<!-- Organization information -->
<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>
- 171 -
ANEXO II
<!-- Catalogue structure-->
<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>
- 172 -
ANEXO II
</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"/>
- 173 -
ANEXO II
<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"/>
- 174 -
ANEXO II
<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>
<!-- Specification categories-->
<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>
- 175 -
ANEXO II
<!-- ************************************************** -->
<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>
<!-- Specifications-->
<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"/>
- 176 -
ANEXO II
<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">
- 177 -
ANEXO II
<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>
<!-- Product Configuration -->
<!-- Product Legs_1 - legs_1a -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_1 - legs_1b -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_1 - legs_1c -->
<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>
<!-- Colour = Yellow -->
<cadainlofo:Specification ref="s_0003"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_1 - legs_1d -->
<cadainlofo:Product_specification id="ps_0004">
<id>legs_1d</id>
- 178 -
ANEXO II
<name>legs_1d</name>
<description>this is a configured leg</description>
<item_context ref="pc_0006"/>
<defining_specifications>
<!-- Colour = Red -->
<cadainlofo:Specification ref="s_0004"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_2 - legs_2a -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_2 - legs_2b -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_2 - legs_2c -->
<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>
<!-- Colour = Yellow -->
<cadainlofo:Specification ref="s_0003"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_2 - legs_2d -->
<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>
- 179 -
ANEXO II
<!-- Colour = Red -->
<cadainlofo:Specification ref="s_0004"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3a -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3b -->
<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>
<!-- Colour = Orange -->
<cadainlofo:Specification ref="s_0005"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3c -->
<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>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3d -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
- 180 -
ANEXO II
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3e -->
<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>
<!-- Colour = Orange -->
<cadainlofo:Specification ref="s_0005"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Legs_3 - legs_3f -->
<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>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1a -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1b -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1c -->
- 181 -
ANEXO II
<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>
<!-- Colour = Yellow -->
<cadainlofo:Specification ref="s_0003"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1d -->
<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>
<!-- Colour = Red -->
<cadainlofo:Specification ref="s_0004"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1e -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1f -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1g -->
<cadainlofo:Product_specification id="ps_0021">
<id>Board_1g</id>
<name>Board_1g</name>
<description>this is a configured board</description>
- 182 -
ANEXO II
<item_context ref="pc_0009"/>
<defining_specifications>
<!-- Colour = Yellow -->
<cadainlofo:Specification ref="s_0003"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_1 - Board_1h -->
<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>
<!-- Colour = Red -->
<cadainlofo:Specification ref="s_0004"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2a -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2b -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2c -->
<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>
<!-- Colour = Orange -->
<cadainlofo:Specification ref="s_0005"/>
- 183 -
ANEXO II
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2d -->
<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>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2e -->
<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>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2f -->
<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>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Board_2 - Board_2g -->
<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>
<!-- Colour = Orange -->
<cadainlofo:Specification ref="s_0005"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
- 184 -
ANEXO II
<!-- Product Board_2 - Board_2h -->
<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>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Table_1 - Table_1a -->
<cadainlofo:Product_specification id="ps_0031">
<id>Table_1a</id>
<name>Table_1a</name>
<item_context ref="pc_0011"/>
<defining_specifications>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Iron -->
<cadainlofo:Specification ref="s_0008"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Table_2 - Table_2a -->
<cadainlofo:Product_specification id="ps_0032">
<id>Table_2a</id>
<name>Table_2a</name>
<item_context ref="pc_0012"/>
<defining_specifications>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Table_3 - Table_3a -->
<cadainlofo:Product_specification id="ps_0033">
<id>Table_3a</id>
<name>Table_3a</name>
<item_context ref="pc_0013"/>
<defining_specifications>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Colour = Blue -->
<cadainlofo:Specification ref="s_0002"/>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
<!-- Material = Plastic -->
- 185 -
ANEXO II
<cadainlofo:Specification ref="s_0010"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Chair_1 - Chair_1a -->
<cadainlofo:Product_specification id="ps_0034">
<id>Chair_1a</id>
<name>Chair_1a</name>
<item_context ref="pc_0014"/>
<defining_specifications>
<!-- Colour = Green -->
<cadainlofo:Specification ref="s_0001"/>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Colour = Orange -->
<cadainlofo:Specification ref="s_0005"/>
<!-- Colour = Red -->
<cadainlofo:Specification ref="s_0004"/>
<!-- Material = Plastic -->
<cadainlofo:Specification ref="s_0010"/>
<!-- Wheels = Whit wheels -->
<cadainlofo:Specification ref="s_0011"/>
<!-- Wheels = Without wheels -->
<cadainlofo:Specification ref="s_0012"/>
<!-- Fabrics = Bourdeaux_01 -->
<cadainlofo:Specification ref="s_0013"/>
<!-- Fabrics = Pistachio_X -->
<cadainlofo:Specification ref="s_0014"/>
</defining_specifications>
</cadainlofo:Product_specification>
<!-- Product Chairs_2 - Chair_2a -->
<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>
<!-- Colour = Black -->
<cadainlofo:Specification ref="s_0007"/>
<!-- Colour = White -->
<cadainlofo:Specification ref="s_0006"/>
<!-- Material = Wood -->
<cadainlofo:Specification ref="s_0009"/>
<!-- Wheels = Without wheels -->
<cadainlofo:Specification ref="s_0012"/>
<!-- Fabrics = Bourdeaux_01 -->
<cadainlofo:Specification ref="s_0013"/>
<!-- Fabrics = Old_Fashion_Aubergine -->
<cadainlofo:Specification ref="s_0015"/>
</defining_specifications>
</cadainlofo:Product_specification>
</exp:uos>
</p28doc:iso_10303_28>
- 186 -
ANEXO III
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:iso1030328: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">
<!-- Catalogue structure-->
<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>
<!-- Properties-->
<!-- Independent properties -->
<cadainlofo:Applied_independent_property id="aip_0001">
<name>ergonomic</name>
<described_element>
- 187 -
ANEXO III
<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>
<!-- Context dependent properties -->
<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>
<!-- Representation and values -->
<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>
- 188 -
ANEXO III
<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>
- 189 -
