Você está na página 1de 200

DESARROLLODEUNAONTOLOGAYDEUN

SISTEMADERECUPERACINDELA
INFORMACINPARAELSECTORDELMUEBLEY
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 desesperacin. Y a mis padres
por confiar en m y apoyarme siempre.

Agradecer especialmente a Miguel ngel Abin, ya no solo por su


gran ayuda, experiencia, dedicacin e inters, sino tambin por su
calidad como persona. Su apoyo, sin duda, ha sido esencial para la
realizacin de este proyecto con xito. Gracias Miguel ngel.

A mi tutor, Javier Samper por su dedicacin y su gran


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

A Mara Jos Nez por ofrecerme la idea y darme la


oportunidad de realizar este proyecto.

A Javi Adel por su experiencia, la atencin que me ha prestado y


su preocupacin cuando le he necesitado.

A mis amigos, Jos Carlos, Lamia, Jorge y Fatha por haber sido
mi familia aqu. Por escucharme y aguantarme en los momentos ms
difciles. Os quiero.

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


etc. Por aquellos aos 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
NDICEGENERAL

AGRADECIMIENTOS..........................................................................III
0. RESUMEN.......................................................................................XI
1. INTRODUCCIN........................................................................2
1.1 INTRODUCCIN......................................................................................................2
1.2 MOTIVACIN.........................................................................................................4
1.3 OBJETIVOS.............................................................................................................5

2. ESTADODELARTE...................................................................6
2.1 NECESIDADDELAINTEROPERABILIDADENLAINDUSTRIADELMUEBLEYAFINES....................6
2.2 FUNSTEP............................................................................................................10
2.2.1. ElproyectoFunStep................................................................................10
2.2.2. ElestndarISOfunStep..........................................................................11
2.2.2.1. LaherramientaCadef....................................................................13
2.3 LAWEBSEMNTICA............................................................................................15
2.3.1. IntroduccinalaWebdetercerageneracin.........................................15
2.3.2. DescripcindelaWebSemntica...........................................................16
2.3.3. Representacindelconocimiento...........................................................19
2.3.4. XML:primerpasohacialaWebsemntica............................................21
2.3.5. Ontologas...............................................................................................23
2.3.5.1 Elementosdeunaontologa..........................................................25
2.3.5.2 TiposdeOntologas.......................................................................26
2.3.5.3 OntologasfrenteaTaxonomas...................................................27
2.3.5.4 Lenguajesdeontologas................................................................28
2.3.5.5 Metodologasylibrerasparaconstruccindeontologas..........35
2.3.5.6 HerramientasparalaconstruccindeOntologas.......................40
2.3.6. BasesdeConocimientofrenteaBasesdeDatos....................................43
2.3.7. Sistemasdealmacenamiento.................................................................43
2.3.8. Razonadores...........................................................................................44
2.3.9. Lenguajesdeconsulta.............................................................................46

3. METODOLOGAYPLANDETRABAJO.............................49
3.1. PLANIFICACINYGESTINDELPROYECTO........................................................49
3.1.1. Definicinderecursos.............................................................................50
3.1.1.1Recursoshumanos............................................................................50
3.1.1.2Recursosdelentorno........................................................................51
3.1.2. Planificacintemporal............................................................................51
3.1.2.1DiagramadeGantt.............................................................................56
3.2. ESTIMACINDECOSTESDELPROYECTO............................................................58
3.2.1. CosteLaboral..........................................................................................58
3.2.1.1Tcnicabasadaenelproceso...........................................................59
3.2.1.2ElmodeloCOCOMO2........................................................................61

V
4. PROCESODEINGENIERA...................................................67
4.1 INTRODUCCIN....................................................................................................67
4.2 ONTOLOGAFUNSTEP.CICLODEVIDA........................................................................67
4.2.1. EspecificacindeRequisitos...................................................................68
4.2.2. AnlisisdelModelodeDatosfunStep....................................................69
4.2.3. AdquisicindeConocimientos................................................................77
4.2.4. EspecificacindelaOntologa................................................................79
4.2.5. Decisionesdediseo...............................................................................80
4.2.6. ConstruccindelaOntologa..................................................................84
4.3 APLICACINDEBSQUEDAWEB............................................................................94
4.3.1. FASEDEANLISIS....................................................................................94
4.3.1.1.Especificacinderequisitos............................................................95
4.3.1.2.Funcionalidadesdelsistema.............................................................97
4.3.1.3.Casosdeuso......................................................................................98
4.3.1.4.DiagramasdeActividad..................................................................102
4.3.1.5.Anlisisdelinterfazdeusuario......................................................105
4.3.2. FASEDEDISEO....................................................................................106
4.3.2.1.DiseodelaAplicacin...................................................................106
4.3.2.2.DiseodelaInterfazdeUsuario....................................................112

5. IMPLEMENTACINYPRUEBAS.......................................115
5.1 FASEDEIMPLEMENTACIN..........................................................................115
5.1.1. ImplantacindelaOntologaenlaAplicacin.....................................117
5.1.2. Notasdeimplementacin.....................................................................119
5.2 PRUEBASYEVALUACIN...............................................................................122
5.2.1. Fundamentosdelaprueba...................................................................122
5.2.2. Pruebasdelsistema..............................................................................122
5.2.3. PruebasdeConsistenciaenlaOntologa..............................................136

6. CONCLUSIONESYTRABAJOFUTURO............................139
6.1. CONCLUSIONES............................................................................................139
6.2. TRABAJOFUTURO........................................................................................141

BIBLIOGRAFA............................................................................143
ANEXOS.........................................................................................145

VI
NDICEDEFIGURAS

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 ontologa ............................. - 14 -
Figura 2.4 Mapa conceptual de la Web semntica (Rodrguez, 2005) ....................... - 17 -
Figura 2.5 Esquema de la web semntica ................................................................... - 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 ontologas establecen redes semnticas .............................................. - 24 -
Figura 2.9 Diagrama de nodos y arcos. ...................................................................... - 31 -
Figura 2.10 Representacin de tripletas RDF. ............................................................ - 31 -
Figura 2.12 Ingeniera y Adquisicin Ontolgica (Goble, 2002) ............................... - 38 -
Figura 2.11 Actividades del ciclo de vida del desarrollo de una ontologa ................ - 37 -
Figura 2.13 El editor de ontologas Protg-OWL. .................................................... - 41 -
Figura 2.14 Ejemplo de OILed 3.4 ............................................................................. - 42 -
Figura 2.15 Arquitectura de un Sistema Terminolgico (Horrocks, 2001). ............... - 45 -
Figura 3.1 Descomposicin del proyecto en tareas .................................................... - 54 -
Figura 3.2 Diagrama de Gantt .................................................................................... - 57 -
Figura 4.1 Implantacin actual de la herramienta Cadef. ........................................... - 69 -
Figura 4.2 Estructura de un catlogo de datos ............................................................ - 70 -
Figura 4.3 Asignacin de propiedades........................................................................ - 71 -
Figura 4.4 Diagrama de informacin detallada sobre Organisation .......................... - 72 -
Figura 4.5 Diagrama de Product_class y sus relaciones ............................................ - 73 -
Figura 4.6 Ejemplo de configuracin 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 ontologa ................................. - 83 -
Figura 4.10 Diferentes niveles de la taxonoma de muebles ...................................... - 85 -
Figura 4.11 Jerarqua 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 Restriccin 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 Bsqueda........................................ - 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 aplicacin...................................................... - 109 -
Figura 4.25 Diagrama de Secuencia del escenario Realizar Bsqueda ................ - 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 bsqueda de muebles de un Fabricante................................ - 126 -

VII
Figura 5.4 Ejemplo de bsqueda de Conjuntos de saln .......................................... - 127 -
Figura 5.5 Ejemplo de bsqueda de Composiciones con camas .............................. - 128 -
Figura 5.6 Ejemplo de bsqueda de camas individuales con cabecero .................... - 129 -
Figura 5.7 Ejemplo de bsqueda de Sillas modenas en Valencia ciudad ................. - 130 -
Figura 5.8 Ejemplo de bsqueda de Sillas con un rango de precio .......................... - 131 -
Figura 5.9 Ejemplo de bsqueda de Mesas de saln 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 ontologa con RacerPro ........................ - 137 -
Figura 6.1 Nueva implantacin del Cadef (Versin beta). ....................................... - 142 -

VIII
NDICEDETABLAS

Tabla 3.1 Estimacin de tiempos del proyecto ........................................................... - 55 -


Tabla 3.2 Estimacin de tiempos del proyecto ........................................................... - 55 -
Tabla 3.3 Costes por hora de cada categora .............................................................. - 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 Ontologa 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 comn y unificado de trminos que represente adecuadamente el
significado (semntica) de los conceptos ms usados en el sector del mueble y afines,
con el objetivo de solventar el importante problema de la falta de interoperabilidad
semntica que existe en esa industria. Este problema dificulta enormemente el
intercambio de informacin 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 bsqueda que facilite al usuario obtener
informacin clara y precisa correspondiente a sus requisitos especficos de bsqueda
(color del mueble, procedencia, dimensiones, precio, etc.).

Algunos aspectos que describen los problemas actuales en cuanto a la bsqueda


de informacin son:

Escasa precisin en los resultados. Algunas bsquedas generan decenas de miles


de pginas que carecen de inters para el usuario; otras, por el contrario, no
generan ninguna.

Alta sensibilidad al vocabulario empleado en la bsqueda. Si los documentos


que realmente interesan no emplean exactamente el mismo vocabulario que la
bsqueda, nunca aparecern.

La herramienta de bsqueda implementada permitir al usuario final encontrar


los muebles que busca; podr especificar las caractersticas que desee y obtener
informacin relevante sobre dichos muebles. Todo esto le permitir, por ejemplo,
comparar precios entre los distintos comercios y localizar fsica o virtualmente aquellos
que le interesen.

Para conseguir los objetivos marcados se han seguido las siguientes etapas:

Construccin de una ontologa cuyo dominio es la informacin sobre la industria


del mueble y afines. La ontologa construida se ha basado en el estndar
internacional de intercambio de informacin especfico del sector del mueble
funStep (ISO 10303-236).

Desarrollo de una base de conocimiento que almacene informacin 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 bsqueda semntica que usar los conceptos


de la ontologa y la informacin almacenada en la base de conocimiento. El
lenguaje de bsqueda escogido ha sido SPARQL.

XI
CAPITULO 1 - INTRODUCCIN

1. INTRODUCCIN

1.1 Introduccin
El rpido desarrollo de la sociedad de la informacin y de sus tecnologas ha
hecho posible la superacin de retos como el almacenamiento de datos. La
comunicacin entre sistemas de informacin heterogneos y distantes geogrficamente
es tambin otro problema resuelto gracias a Internet y a la universalidad de sus
protocolos de comunicacin. Con todo, an existen algunos retos que superar. A saber:
la bsqueda de informacin y su integracin. El ejemplo ms claro se encuentra en
Internet. A pesar de la cantidad de informacin 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 informacin deseada. Segn
muchos autores, la solucin a estos radica en el uso de metadatos y ontologas.

Los metadatos son datos que a su vez describen datos, y denotan cualquier tipo
de informacin sobre la estructura y el contenido de un recurso, ya sea un documento
HTML, una imagen, un documento de vdeo, un conjunto de datos o cualquier otro
recurso. En el campo del almacenamiento y recuperacin de la informacin, los
metadatos permiten acceder ms fcilmente a los recursos que los incluyen. Una de las
facetas ms interesantes de los metadatos es su utilidad para conseguir la
interoperatividad entre diferentes sistemas de informacin, que pueden estar basados
en distintas concepciones y tecnologas.

Los metadatos estructuran solamente los contenidos; las ontologas permiten


estructurar la semntica (significado) de un recurso. Las ontologas establecen
formalmente los conceptos de un cierto dominio la palabra dominio denota un rea
especfica de inters o un rea de conocimiento y sus relaciones, pudiendo ser
compartidas por todos. Toda ontologa representa cierta visin del mundo con respecto a
un dominio. Su uso proporciona una forma de representar y compartir conocimiento
haciendo uso de un vocabulario comn e inambiguo.

Las ontologas favorecen la comunicacin entre personas, organizaciones y


aplicaciones porque proporcionan una comprensin comn de un dominio, de modo que
se eliminan confusiones conceptuales y terminolgicas.

Favorecen tambin la comunicacin entre aplicaciones y la comprensin comn


de la informacin entre ellas. Sern imprescindibles tanto en la Web semntica como en
los futuros sistemas de gestin empresarial porque permitirn que las aplicaciones estn
de acuerdo en los trminos que usan cuando se comunican. Mediante ellas, ser mucho
ms fcil recuperar informacin relacionada temticamente. Empresas como Autonomy,
FAST, Endeca y Newssift ya trabajan con herramientas semnticas para gestionar los
datos incluidos en los centros de datos de grandes compaas y realizar bsquedas en
ellos.

Las ontologas sirven tambin para conseguir que los sistemas interoperen.
Dos sistemas son interoperables si pueden trabajar conjuntamente de una forma

-2-
CAPITULO 1 - INTRODUCCIN

automtica, 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 ao 1998 naci el proyecto funStep
con los siguientes objetivos principales:

Generar un modelo de informacin comn para el mueble.

Desarrollar un mtodo comn para el intercambio de informacin


telemticamente.

En definitiva, el proyecto funStep vino a mejorar la interoperabilidad (sintctica)


en el sector mobiliario, con las ventajas que ello conlleva: la interoperabilidad ayuda a
las empresas a producir bienes y servicios ms rpidamente y a un coste ms reducido.
Este proyecto culmin en el estndar internacional de intercambio de informacin del
sector mobiliario: ISO 10303-236.

El departamento de Tecnologas de de Informacin (TI) de AIDIMA, empresa


donde se ha realizado este proyecto y una de las empresas colaboradoras en funStep,
tuvo la iniciativa de ir ms all e intentar conseguir la interoperabilidad completa
(sintctica y semntica) entre las empresas del sector mobiliario. La falta de esta
interoperabilidad en el comercio electrnico B2B produce grandes problemas, como por
ejemplo la dificultad de comunicacin entre empresas que definen de diferente manera
objetos de negocio como pedido o producto; o la dificultad de realizar transacciones
electrnicas 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 construccin de una ontologa que defina los conceptos relacionados con el


sector mobiliario, proporcionando as un vocabulario comn, aumentara la
competitividad de las empresas, su flexibilidad y eficiencia. Y dara lugar a beneficios
econmicos tanto para las empresas como los consumidores.

Por ello, la primera meta de este proyecto es conseguir dicha ontologa, que
permitir catalogar la informacin mediante el significado de las palabras relacionadas
con el sector en cuestin. Gracias al conocimiento almacenado en ella, las aplicaciones
podrn extraer automticamente o semiautomticamente datos de las pginas 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 ontologa, es la bsqueda de informacin
relacionada con los muebles y afines (telas, accesorios, materiales, etc.). A da de hoy
existe en la web algn que otro buscador de comercios de muebles, fabricantes o
proveedores y existen pginas 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 caractersticas
que desea, comparar precios de distintos comercios, consultar distintos catlogos y,
sobre todo, obtener resultados exactos que se ajusten a sus necesidades, sin tener que
perder mucho tiempo. Esto se puede conseguir empleando las tecnologas semnticas

-3-
CAPITULO 1 - INTRODUCCIN

disponibles en la actualidad (RDF(S), OWL, SPARQL, etc.) y haciendo uso de la


ontologa de mobiliario y afines creada. Con el fin de desarrollar una de las muchas
posibles aplicaciones que ofrece la ontologa (catalogacin electrnica, integracin
automtica de catlogos electrnicos de distintos fabricantes, anotacin semntica de
recursos relacionados con muebles, introduccin 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 informacin sobre muebles que utilice la
ontologa de mobiliario y afines para resolver una serie de consultas de gran inters 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 Motivacin
La idea de realizar este proyecto surgi durante una entrevista que mantuve con
la directora del departamento de Tecnologas de la Informacin (TI) de AIDIMA, Da.
Mara Jos Nez, donde realic prcticas en empresa durante el curso 2007/08. Este
departamento ha participado en docenas de proyectos internacionales relacionados con
las tecnologas de la informacin; y ha desarrollado y promueve funStep (ISO 10303-
236), el estndar internacional en el sector del mueble para el intercambio de
informacin en sistemas CAD.

En el momento de la entrevista quera comenzar mi proyecto final de carrera y


me interesaba que estuviera relacionado con el uso de ontologas y bsquedas
semnticas, pues lo considero un campo de la informtica con mucho futuro. Este
inters lo despert en m por primera vez el catedrtico D. Gregorio Martn durante las
clases de la asignatura TIC (Tecnologas de la Informacin y de la Comunicacin).
Posteriormente, adquir unos conocimientos bsicos sobre RDF y ontologas en la
asignatura IST (Ingeniera de Servicios Telemticos) 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 Semntica, 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 mquinas, y que permita hacer deducciones
automticas a partir de ellos, consiguiendo as que las mquinas 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 aos, junto con otros centros colaboradores, de
fomentar la utilizacin de un vocabulario comn y unificado en la industria del mueble
y afines. Para ello, se comenz a construir una jerarqua que clasificara trminos 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 ontologa que clasifique y defina formalmente los conceptos ms
usados del sector en cuestin, as como la de desarrollar un prototipo de buscador que
utilice los conceptos de la ontologa creada, para probarla y demostrar algunas de las
funciones y posibilidades que tiene el uso de esta ontologa. Para ello puso a mi
disposicin a D. Miguel ngel Abin, investigador de AIDIMA con ms de 14 aos de
experiencia en proyectos de I+D nacionales e internacionales.

-4-
CAPITULO 1 - INTRODUCCIN

Personalmente, me pareci muy interesante contribuir, aunque fuera en pequea


medida, al proyecto de la Web semntica, estableciendo semntica en un dominio como
el del mobiliario y afines. ste es un sector relevante y estratgico para la Comunidad
Valenciana y carece de un vocabulario comn, imprescindible para la catalogacin 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 comn, expresado formalmente, para representar


informacin relacionada con el sector del mobiliario y afines (telas, accesorios,
materiales, etc.). Esto es, desarrollar una ontologa que defina los conceptos ms
usados en la industria del mobiliario y afines, sus propiedades y las relaciones
entre ellos. Esta ontologa debe basarse en funStep, el estndar internacional de
intercambio de informacin en sistema CAD.

2) Crear una base de conocimiento que almacene algunas instancias de muebles e


informacin relacionada con el sector, con el fin de probar la ontologa creada.

3) Desarrollar un prototipo de una aplicacin web de bsqueda de muebles, basada


en tecnologa semntica y que utilice los conceptos de la ontologa y la
informacin almacenada en la base de conocimiento para resolver consultas que
sean del inters de los usuarios.

-5-
CAPITULO 2 ESTADO DEL ARTE

2. ESTADODELARTE

2.1 Necesidaddelainteroperabilidadenlaindustriadel
muebleyafines

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 podan intercambiar y
ensamblar de manera sencilla; es decir, un sistema de componentes interoperables.
Antes de Ford las piezas se construan y se ensamblaban de manera personalizada para
cada automvil.

Igualmente, el xito de la industria electrnica y de la telefona, sea mvil o fija,


se deben a la interoperabilidad. En electrnica 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 telefona, redes telefnicas de
pases distintos, cada una con sus estndares y componentes telemticos, interoperan
para que personas separadas por miles de kilmetros puedan hablar.

Para entender bien esto, veamos algunas definiciones de interoperabilidad:

La capacidad de dos entidades (tpicamente 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 travs de aplicaciones de
software, a pesar de que stas tengan diferentes sistemas de smbolos.

La capacidad para compartir e intercambiar datos que usan sintaxis y


semnticas comunes para encontrar una relacin funcional de
aplicacin especfica empleando un interfaz comn.

Segn la IEEE (Institute of Electrical and Electronics Engineers) la


interoperabilidad es:

La capacidad de dos o ms sistemas o componentes para intercambiar


informacin (interoperabilidad tcnica y sintctica) y usar la informacin que ha sido
intercambiada (interoperabilidad semntica).

Existen tres niveles de interoperabilidad, mencionados en el prrafo anterior


(Abin, 2005):

Interoperabilidad tcnica. Se refiere a la capacidad de dos sistemas


informticos (SI) de intercambiar seales. Exige una conexin fsica y un
conjunto de protocolos de comunicacin. Que dos SI interoperen tcnicamente
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 sintctica. Se refiere a la capacidad de los SI para leer los


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

Interoperabilidad semntica. Es la capacidad de los SI de intercambiar la


informacin basndose en un comn significado de los trminos 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 dlares; y el
otro, con facturas donde ese campo significa el Importe de la factura en euros.
Evidentemente, ambos SI carecen de interoperabilidad semntica.
La interoperabilidad semntica no debe confundirse con la sintctica: sta se
refiere a la dificultad de procesar automticamente los datos, no a su
contenido. Aquella se refiere a la dificultad de relacionar los trminos
desconocidos que aparecen en los datos con los ya conocidos o definidos. La
interoperabilidad semntica no puede existir antes de la tcnica y de la
sintctica.

La interoperabilidad es muy importante para las empresas porque ayuda a


producir bienes y servicios ms rpidamente, a coste ms reducido, manteniendo los
niveles de calidad y personalizacin ms altos. Las empresas y organizaciones deben ser
capaces de adaptarse a cambios del mercado por la externalizacin eficiente y
estrategias de colaboracin (Abin et al., 2004).

A pesar de que muchas aplicaciones usen tecnologas unificadas (p.ej., XML


para describir datos) los modelos de datos y de negocio permanecen heterogneos.
Incluso nociones muy comunes, como pedido o cliente pueden variar enormemente
entre distintas aplicaciones. Esto significa que hay una falta de interoperabilidad
semntica en el comercio electrnico B2B, que produce grandes problemas: Cmo van
a entenderse empresas que definen de manera distinta objetos de negocio como
pedido o producto? Cmo van a realizar transacciones electrnicas dos empresas
que entienden precio de distintas maneras (una como la cantidad que figura en su
catlogo; otra, como esa cantidad ms impuestos y ms gastos de envo)?

Para conseguir la interoperabilidad se necesita integrar tres componentes


temticos (Vallespir et al., 2004):

Arquitecturas y plataformas para proporcionar la implementacin de soluciones.

Un modelo de negocio para definir los requisitos de la interoperabilidad y


apoyar la implementacin de soluciones.

Ontologas para identificar semnticas 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 informacin electrnicamente. En general, las
PYMES ven la interoperabilidad como una cuestin tcnica y no como una capacidad
(Magali et al., 2004).

Centrndonos en el sector del mobiliario, vamos a ver los problemas de la


interoperabilidad relacionados con ontologas:

Debido a que las PYMES no usan un vocabulario comn, existe una falta de
diccionarios de datos interoperables. Varias grandes organizaciones de estndares que
han desarrollado los diccionarios de datos electrnicos han reconocido que una parte de
la solucin de este problema es la armonizacin entre los diccionarios internacionales
disponibles. El primer paso para el intercambio de informacin entre los componentes
econmicos de las fronteras nacionales es la capacidad de utilizar la misma
terminologa.

Hay una gran necesidad de transferir datos diseos CAD, pedidos, albaranes,
facturas, etc.- de forma estructurada entre fabricantes, distribuidores, clientes, etc. En la
industria de diseo de interiores, hoy en da esto es casi imposible de hacer sin grandes
inversiones por parte de cada uno de los fabricantes. La nica manera de simplificar y
hacer ms eficiente este proceso es llegar a un acuerdo sobre una ontologa comn para
los datos relacionados con el producto.

Por ejemplo, la palabra mueble es aplicable a una gran variedad de productos


con diferentes caractersticas. Para poder definir una mesa de oficina ajustable
elctricamente o una cama de hospital, se necesita poder seleccionar criterios para
aparatos elctricos. Y para ser capaces de definir mobiliario con componentes de
iluminacin, como muebles de bao con luminarias, debe poderse seleccionar criterios
relativos a la iluminacin.

-8-
CAPITULO 2 ESTADO DEL ARTE

La parte principal de comunicacin de datos sucede entre los productores y los


minoristas, muchas veces con uno o varios agentes / distribuidores entre ellos. No basta
encontrar una solucin de la parte de recepcin para los proveedores de mobiliario; los
minoristas tambin reciben datos de los proveedores de componentes de iluminacin,
telas, etc. Otros receptores de informacin que necesitan manejar ms informacin que
los datos de muebles son los agentes de informacin de Internet, los desarrolladores de
software, los arquitectos y diseadores de interiores etc. En este sentido, la ontologa
debe ser capaz de manejar casi todos los productos manejados por los receptores de
informacin.

Algunos ejemplos:

Producto = Nombre usado para un producto de diseo de interior u exterior


o parte de un producto que se vende como un producto por separado

Ejemplos de productos de diseo de interiores: Sof-cama, mesa de


comedor, armario de cocina, mesa de oficina ajustable elctricamente

Productos de diseo de exteriores: Banco, mesa de jardn, macetero,


hamaca.

Partes de productos que se pueden vender como productos separados:


cabecero (para una cama), barra o palo (para una lmpara).

Productor = Nombre para el productor o fabricante de un producto.

Finalmente, veamos algunos aspectos tenidos en cuenta en el trabajo de


clasificacin de la ontologa objeto de este proyecto:

Las organizaciones relacionadas con la industria del mobiliario debern


clasificarse en diferentes categoras de empresas, como fabricante, distribuidor y
minorista.

Se deben definir dimensiones y unidades que se utilizarn a la hora de transferir


datos de produccin, de catlogos y de comercio electrnico.

Los materiales usados en la industria del mueble se deben describir y agrupar en


diferentes clases.

La existencia de una ontologa 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 econmicos, tanto para las empresas como los consumidores.

-9-
CAPITULO 2 ESTADO DEL ARTE

2.2 FunStep

2.2.1. ElproyectoFunStep
El proyecto funStep surge debido a la necesidad que tienen los fabricantes y
tiendas de mobiliario de intercambiar informacin de producto, tanto grfica como
textualmente independiente del sistema informtico utilizado.

En el mercado hay disponible una amplia oferta de sistemas de CAD


especializados en la decoracin de interiores, pero esos sistemas no permiten el
intercambio de informacin entre ellos. Por otro lado, no existe una solucin completa
para la industria del mueble basada en EDI (Electronic Data Interchange).

La mayora de los fabricantes y sus clientes consideran esta incompatibilidad


como el principal escollo para rentabilizar las inversiones, de forma que deciden retrasar
la decisin, esperando a que se clarifique la situacin del mercado. Como consecuencia,
no mejoran la gestin de la informacin 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
informacin, que apareceran en la relacin diaria con el cliente.

Debido a este importante problema industrial naci el proyecto funStep en 1998


con los siguientes objetivos:

Generacin de un modelo de informacin comn para el mueble.


Desarrollo de los traductores necesarios para algunos sistemas CAD
comerciales, especializados en el mueble.
Desarrollo de mtodos de comprobacin y certificacin de programas CAD
conformes con el modelo funStep.
Desarrollo de un mtodo comn para el intercambio de informacin va
telemtica.
Demostracin de la compatibilidad de sistemas CAD comerciales,
intercambiando informacin 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 inversin.
Mejora del servicio al cliente.
Reduccin de la carga de trabajo no productivo.
Apertura a la posibilidad del Comercio Electrnico.
Reduccin 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,
liberndolos de la introduccin de libreras de fabricantes.
Una nueva funcionalidad en los paquetes: mdulos para intercambio de datos
va telecomunicaciones.

2.2.2. ElestndarISOfunStep

FunStep es una iniciativa nacida en 1998 como ya se ha mencionado


anteriormente - alrededor de la ISO funStep, el estndar internacional para el
intercambio de datos en las industrias del muebles y de diseo de interiores,
formalmente conocida como la ISO 10303-236 " Sistemas de automatizacin industrial
e integracin - representacin e intercambio de los datos de Producto - Parte 236:
Protocolo de aplicacin: Catlogo de muebles y diseo de interiores.

Este estndar considera asuntos como:

Product catalogue data (Informacin de productos de catlogo)


Pricelists (Precios)
Product Composition (Composicin de productos)
Product Breakdown (Desglose de producto)
Properties (Propiedades)
Parametric product configuration (parmetros de configuracin de
productos)
Multilingual data (Multilenguaje)
Documentation assignment (asignacin de documentacin)
Ms.

El estndar interpreta la informacin 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 tambin con los
diseadores y arquitectos.

Proporciona a travs de un modelo de datos comn, un mecanismo neutro capaz


de describir productos a travs de su ciclo de vida: requisitos, tarifa tcnica, diseo
detallado, procesos de fabricacin, escandallo, asociacin con geometra, catalogacin
estructurada, gestin documental relacionada con pedidos, etc.

La informacin es representada en XML (eXtensible Markup Language),


facilitando el envo de los datos antes mencionados entre las diferentes compaas y los
distintos sistemas informticos. El modelo se describe tambin en diagramas UML
(Unified Modeling Language) hacindolo compatible con sistemas de bases de datos
relacionales.

Las posibles aplicaciones del modelo de datos funStep son prcticamente

- 11 -
CAPITULO 2 ESTADO DEL ARTE

ilimitadas, pero algunos de los usos previstos inicialmente incluyen:

Distribucin de informacin de catlogos de muebles desde una fuente nica a


varios portales web.

La combinacin de datos de los catlogos de varias fuentes en un nico sistema


de gestin de venta al por menor.

La importacin de especificaciones de componentes de mltiples proveedores en


un diseo de muebles o sistema de fabricacin.

Generacin de ventas de materiales en formato impreso y electrnico.

Intercambio y la reutilizacin de modelos de informacin grfica.

Proporcionar datos de productos para el diseo de interiores y diseo de


herramientas (por ejemplo, software de diseo de la cocina o el cuarto de bao).

El beneficio principal de la adopcin del modelo de datos de la Norma ISO


funStep es el aumento de la eficiencia que se deriva de compartir datos entre distintos
sistemas informticos, sin la necesidad de volver a introducir la informacin,
reduciendo as las posibilidades de errores humanos y el tiempo de transaccin 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 estndar ISO
funStep significa que, por ejemplo, los proveedores de componentes puedan
proporcionar la informacin tcnica completa sobre sus productos a los fabricantes que,
a su vez, pueden proporcionar informacin sobre los productos a los minoristas,
publicar catlogos, operar con los sistemas de comercio electrnico, gestin de sistemas
de control de existencias o el suministro de datos para el diseo de interiores, todo, sin
la necesidad de introducir ningn dato ms de una vez.

Como se ver ms adelante, la norma funStep se ha utilizado en el desarrollo de


la ontologa 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 aplicacin de este estndar se presenta la herramienta de


definicin de catlogos: Cadef (CAtalog DEFinition). Mediante esta herramienta se
generan los catlogos electrnicos de muebles, que se pueden representar en ficheros
XML. En el diseo de la ontologa se tendr en cuenta el modelo de datos de esta
aplicacin ya que en un futuro se pretende enlazarla con la ontologa para transcribir los
ficheros XML a RDF y obtener un modelo semntico. Los ficheros obtenidos en OWL
contendrn las instancias de muebles.

- 12 -
CAPITULO 2 ESTADO DEL ARTE

2.2.2.1. LaherramientaCadef

Cadef (CAtalog DEFinition) es una herramienta de software para el proceso de


generacin de catlogo de las empresas relacionadas con la industria del mueble. Como
herramienta de configuracin, permite la definicin y la gestin de especificaciones de
los productos.

Dado que esta herramienta est construida bajo el estndar funStep, soporta
varias funcionalidades adicionales interesantes para el fabricante: vnculos multimedia,
enlaces a dibujos CAD2D y 3D, el desglose de productos, restricciones, precios segn
configuracin, definicin de las partes constituyentes de un mueble, materiales, telas,
herrajes,

Al ser una herramienta nativa de implementacin del estndar 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 implantacin actual, enlazndola con la ontologa 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 ontologa

- 14 -
CAPITULO 2 ESTADO DEL ARTE

2.3 LaWebSemntica

2.3.1. IntroduccinalaWebdetercerageneracin
El mundo de la WWW ha permitido en la ltima dcada disponer de un volumen
de informacin que hasta el momento era impensable por vas tradicionales. Esto, al
mismo tiempo que ha propiciado el xito de la Web, tambin ha originado sus
principales problemas: sobrecarga de informacin y heterogeneidad de fuentes de
informacin, lo cual resulta en un grave problema de interoperabilidad.

La Web actual no incluye mecanismos para la interoperabilidad completa de los


sistemas de informacin (SI) basados en la Web. Dicho de otra manera: no facilita la
creacin de una comprensin comn y compartida de un dominio, de forma que sta
pueda ser usada por personas, organizaciones y mquinas. Esta falta de
interoperabilidad produce grandes problemas en el comercio electrnico B2B como se
ha comentado en apartados anteriores.

El problema de la sobrecarga de informacin provoca dificultad para acceder a la


informacin de la Web. Para ilustrar el problema, el ejemplo de los buscadores actuales
es muy indicativo. Los motores de bsqueda 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 eleccin 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 pginas hasta encontrar la informacin deseada. Hasta el
momento la intervencin humana resulta imprescindible para seleccionar la informacin
que uno desea.

Si las pginas web se escribieran en un lenguaje que permitiera almacenar


semntica, los buscadores web encontraran no solo las pginas donde aparecieran las
palabras de la bsqueda, sino tambin todas aquellas pginas donde hubiera sinnimos
de esas palabras.

No son los buscadores web los responsables finales de la dificultad para


encontrar informacin en la Web, sino el lenguaje utilizado para construir las pginas
web: HTML. Este lenguaje de etiquetado slo permite especificar cmo se va a mostrar
una pgina HTML, pero resulta intil para dar contexto a una pgina. HTML no
proporciona semntica a los datos.

Los problemas comentados anteriormente ocasionan que el usuario nunca tenga


la garanta de que ha encontrado toda la informacin relevante para su consulta. No
debemos olvidar que los usuarios no pueden acceder a la informacin almacenada en
imgenes, vdeos o archivos de sonido. En todo caso, pueden acceder a las
descripciones textuales de esos archivos, si tienen. En caso contrario, el buscador jams
lo encontrar.

La Web semntica propone superar las limitaciones anteriormente citadas de la


Web actual, permitiendo a los usuarios delegar tareas en el software. Tiene como visin

- 15 -
CAPITULO 2 ESTADO DEL ARTE

la bsqueda de una Web ms inteligente, en la que se pueda conseguir una


comunicacin efectiva entre ordenadores, y centra sus esfuerzos principalmente en la
bsqueda de descripciones enriquecidas semnticamente para los datos en la Web. En
este sentido, se promueven descripciones que incluyan, no solo las estructuras de datos,
sino tambin las relaciones existentes con otros conceptos, las restricciones, reglas que
permitan realizar inferencia, etc. Asimismo, se promueve la definicin y reutilizacin de
vocabularios y ontologas de conceptos que faciliten el procesamiento por parte de las
mquinas (Berners-Lee, 2001). stas podrn, 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 electrnico y la bsqueda de informacin de manera
eficaz y precisa.

2.3.2. DescripcindelaWebSemntica

La Web semntica es una extensin de la Web actual en la que se proporciona


la informacin con un significado bien definido, mejorando la forma en que los
ordenadores y las personas trabajan en cooperacin (Berners-Lee, 2001).

La definicin formal de la Web semntica dada por el W3C se resume en las


siguientes lneas:

El propsito de la iniciativa de la Web semntica es tan amplio como el de la


Web: crear un medio universal para el intercambio de datos. Se considera para
interconectar eficazmente la gestin de la informacin personal, la integracin
de las aplicaciones empresariales y compartir globalmente datos comerciales,
cientficos y culturales. Los servicios para poner datos comprensibles por las
mquinas se estn convirtiendo rpidamente en una propiedad para muchas
organizaciones, individuos y comunidades.

La Web slo puede alcanzar todo su potencial si llega a ser un sitio donde se
puedan compartir datos y sean procesados por herramientas automticas, as como por
personas. Para adaptarse a la Web, los programas del maana deben ser capaces de
compartir y procesar datos incluso cuando estos programas se hayan diseado de forma
completamente independiente. La Web semntica es una iniciativa del consorcio World
Wide Web (W3C), diseada para desempear un papel de liderazgo en la definicin de la
Web. ste desarrolla especificaciones abiertas para aquellas tecnologas que estn
preparadas para distribuciones a gran escala, e identifica -mediante el desarrollo
avanzado de cdigo abierto- los componentes de la infraestructura que en el futuro se
necesitarn adaptar a la Web.

En la figura 2.4 se muestra el mapa conceptual de la Web semntica, orientado a


la comprensin, de forma general, de los componentes y tecnologas que integran el
modelo de la Web semntica, 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 semntica (Rodrguez, 2005)

La Web semntica se basar en que las mquinas comprendan el significado de


la informacin disponible en ella; de ah el adjetivo semntica. 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 aos, digamos que la
interpretacin semntica la proporcionan nuestras estructuras neuronales. Pero para las
mquinas actuales, comprender no debe entenderse en el sentido de comprensin
humana, sino en el sentido de inferir, deducir. Que las mquinas entiendan o
comprendan los datos significa que, mediante procesos lgico-matemticos, sean
capaces de inferir conclusiones a partir de los datos.
Hoy en da, existen ya - segn diversos autores - las tecnologas que llevarn a la
Web semntica. 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 Semntica. El diagrama de la figura 2.5, presentado por Berners-Lee en
la XML Conference del ao 2000, puede servir como aproximacin visual al conjunto de
tecnologas que forman el esquema de capas mencionado, cuyos componentes son:

Estndares para la localizacin de recursos de informacin en el web de forma


inequvoca y nica como son los URIs (Uniform Resource Identifiers) y la
norma internacional Unicode para la codificacin de caracteres a nivel
internacional.
- 17 -
CAPITULO 2 ESTADO DEL ARTE

XML (eXtensible Markup Language ), como base sintctica para la


estructuracin del contenido en el web, as como el empleo de espacios de
nombres (Namespaces) para asociar con precisin cada propiedad con el
esquema que define dicha propiedad y esquemas (XML Schema ) para definir
qu elementos debe contener un documento XML, cmo estn organizados,
qu atributos y de qu tipo pueden tener sus elementos.
Un modelo bsico 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 representacin de ontologas que permitan la
interoperabilidad y reutilizacin entre ontologas de diversos dominios del
conocimiento en el web, cuya base se encuentra en RDF Schema .
Una capa lgica que permita realizar consultas e inferir conocimiento; donde
estaran las ontologas, agentes de software y servicios web como estructuras
para lograr interoperabilidad entre aplicaciones y sistemas de informacin
heterogneos.
Una capa de seguridad que permita asignar niveles de fiabilidad a
determinados recursos, de forma comprobable posteriormente por los
agentes, para lo que se utilizarn firmas digitales y redes de confianza.

Figura 2.5 Esquema de la web semntica

La unin de todas estas capas producira una Web Semntica potente, segura y
amigable.

En los prximos apartados hablaremos ms sobre estas tecnologas. Con ellas, la


Web pasar de ser una coleccin de documentos a ser una base de conocimiento, de la
cual se podrn extraer conclusiones a partir de premisas.

- 18 -
CAPITULO 2 ESTADO DEL ARTE

2.3.3. Representacindelconocimiento

El concepto de documentos que las mquinas puedan entender no implica


ninguna inteligencia artificial que permita a la mquina comprender los murmullos
humanos. Slo indica la habilidad de la mquina para resolver un problema bien
definido desarrollando operaciones bien definidas sobre datos bien definidos. En lugar
de pedir a las mquinas que entiendan el lenguaje humano, implica pedir a la gente que
haga un esfuerzo (Berners-Lee, 1998).

La expresin pedir a la gente que haga un esfuerzo significa que los humanos
deben representar los datos en algn lenguaje formal (lgico y axiomtico), de manera
que las mquinas puedan usarlos para extraer inferencias lgicas. Estos lenguajes,
vinculados a la representacin del conocimiento, se conocen como lenguajes de
representacin de conocimiento.

Se han utilizado diversos formalismos para representar el conocimiento en los


sistemas de informacin. En bases de datos se han utilizado diagramas entidad-relacin
para definir los conceptos y sus relaciones en un determinado universo. En
programacin se han utilizado gramticas y estructuras de datos como clases y objetos.
En Ingeniera del Software se ha propuesto el uso de lenguajes de modelado como
UML, donde tambin se pueden definir clases y sus relaciones.

En Inteligencia Artificial, algunas de las formas que se han utilizado para


representar el conocimiento son la lgica matemtica y las estructuras de datos.

En la lgica matemtica destacan los enfoques basados en lgica y los basados


en reglas.

Los sistemas basados en lgica utilizan frmulas lgicas para representar


relaciones complejas. Dentro stos, las que tienen el poder expresivo ms alto son las
lgicas 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 lgica 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 semntica de orden mayor, sta puede ser simplificada en lgica de primer
orden (LOP) (Samper, 2005). La Lgica 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 semntica 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 lgicas descriptivas (cada familia de lgicas descriptivas se origina de un
determinado subconjunto de la LOP). Es cierto que las lgicas descriptivas carecen de la
potencia expresiva de la LOP, sin embargo son matemticamente trazables y son
computables.

Por otra parte los sistemas basados en reglas permiten representar el


conocimiento en formas de clusulas IF-THEN u otras condiciones de accin. 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 relacin con los sistemas de representacin del conocimiento basados en


estructuras de datos, se destacan los siguientes:

Redes semnticas: 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 representacin basados en marcos insisten en
una organizacin jerrquica, mientras que las redes semnticas no requieren de
tal organizacin

Redes de herencia estructurales: Desarrolladas para subsanar las


ambigedades de las dos anteriores, y su puesta en prctica se realiz en el
sistema KL-ONE (Brachman, 1985, citado por Samper, 2005; Brachman, 1978,
citado por Samper, 2005).

Sistemas terminolgicos o Descripciones Lgicas: Son un tipo de lenguaje de


representacin basado en lgica que ha sido diseado para razonar sobre redes
semnticas y frames.

Grafos, Redes de Petri, Mapas Tpicos: Son estructuras de representacin de


ms bajo nivel que constituyen la base formal de otros mecanismos recientes de
representacin del conocimiento.

John F. Sowa afirma que la representacin de conocimiento es un rea


multidisciplinar que aplica teoras y tcnicas de los campos de la Lgica, Ontologas y
la Computacin. Para este autor, la lgica provee la estructura formal y las reglas de
inferencia, y sin ella no existirn criterios para determinar si hay sentencias
contradictorias o redundantes. Las ontologas permiten que los trminos y smbolos que
existen en el dominio de aplicacin estn bien definidos y no den lugar a confusin. Por
ltimo, los modelos de computacin permitirn implementar las dos primeras
disciplinas en programas de aplicacin (Sowa, 2000, citado por Samper, 2005).

Resumiendo lo anterior, se puede concluir que la lgica es relevante para la Web


semntica por tres motivos:

1) Permite desarrollar lenguajes formales que permiten representar el


conocimiento.

2) Proporciona semnticas bien definidas: en un sistema lgico, cada smbolo y


cada expresin 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 interpretacin semntica automtica de
documentos no pasa de ser la aplicacin de reglas lgicas a unos datos

- 20 -
CAPITULO 2 ESTADO DEL ARTE

presentados en algn lenguaje formal (como OWL, DAML, DAML+OIL o


KIF/CL). Estos lenguajes se basan en la lgica descriptiva (lgica que
proporciona un formalismo para expresar el conocimiento humano,
basndose en mtodos de razonamiento bien establecidos y procedentes de
un subconjunto de la lgica de predicados o de primer orden).

2.3.4. XML:primerpasohacialaWebsemntica

XML (eXtensible Markup Language) fue desarrollado por el grupo de trabajo


XML del W3C, que estableci la segunda edicin de la versin 1.1 como recomendacin
el 16 de agosto del 2006 (XML, 2006). Se desarroll para proporcionar una flexibilidad
y eficiencia que no se podan 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 aparicin de XML en 1998, se han definido multitud de estndares para


modelizar informacin en dominios especficos como las finanzas (XBRL, RIXML,
etc.), el periodismo (p.e. News ML, PRISM), la enseanza (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 sintctica,


que es necesaria para el comercio electrnico. 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. Adems de almacenar los datos, almacena la estructura de


stos. Resulta fcil 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 produccin, albaranes, reclamaciones...) y
que exija a sus clientes y proveedores que usen documentos XML conformes a
esos esquemas o DTDs.

La comprobacin de la estructura de los documentos se puede hacer de forma


automtica, de modo que se rechacen aquellos documentos que no estn
construidos siguiendo los esquemas o DTDs elegidos. Con lo que se evita el
envo de documentos incorrectos.

Al basarse en texto ordinario, los documentos XML son idneos para


transportarlos a travs de Internet; red donde conviven muchas plataformas y
sistemas informticos 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 direccin de avanzar hacia una representacin


explcita de los datos y la estructura de los contenidos de la web, separada de su
presentacin en HTML. XML proporciona una sintaxis para hacerlo posible, pero ofrece
una capacidad limitada para expresar la semntica. El modelo de datos XML consiste en
un rbol que no distingue entre objetos y relaciones, ni tiene nocin de jerarqua de
clases.

Por lo tanto, a pesar de todas las excelencias de XML, no proporciona una


interoperabilidad completa, pues no incorpora ningn mecanismo para garantizar la
interoperabilidad semntica. XML sirve para especificar el formato y estructura de
cualquier documento; pero no impone ninguna interpretacin comn 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 ningn mecanismo para la
interpretacin semntica 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 surgirn 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
semnticamente equivalentes.

Sin embargo, XML es el pilar en el que sustentan el resto de lenguajes o


tecnologas de la Web. XML supone un formato universal: Todo debe estar escrito en
XML (Llrens, 2005).

Otra de las funciones actuales que tiene es encapsular la informacin o partes de


una ontologa para que sea intercambiada a travs de los diferentes protocolos de
intercambio de datos XML a travs de la Web (por ejemplo SOAP).

La familia de las tecnologas asociadas a XML es muy extensa destacando


Xpath, XPointer, XLink, XSL y CSS principalmente (Martn, 2005).

2.3.5. Ontologas

El trmino Ontologa proviene de la filosofa y es una teora que trata de la


naturaleza y organizacin de la realidad, es decir de lo que existe. Conocimiento del
ser (del griego onto: ser y logos: conocimiento).

La definicin de ontologa ms concisa es la del consorcio W3C: La ontologa


es un trmino tomado prestado de filosofa que se refiere a la ciencia de describir los
tipos de entidades en el mundo y cmo se relacionan entre ellos. (MacGuinness y
Harmelen, 2004)

La definicin ms empleada en la literatura de Web Semntica procede de


Gruber: Una ontologa es una especificacin explcita y formal de una
conceptualizacin (Gruber, 1993). En esta definicin, conceptualizacin significa un
modelo abstracto; explcita significa que los elementos deben ser claramente definidos;
y formal significa que la especificacin debe ser procesable por una mquina. Yendo
ms lejos, desde el punto de vista de Gruber, una ontologa es la representacin del
conocimiento de un dominio, donde un conjunto de objetos y sus relaciones son
descritos por un vocabulario. Puede decirse que una ontologa define un vocabulario
comn para los que necesitan compartir informacin sobre un dominio.

Cabe sealar que no todas las ontologas deben ser formales: existen ontologas
que se expresan de una forma restringida y estructurada del lenguaje natural, e incluso
mediante el lenguaje natural (espaol, francs, ingls,).

En lo que sigue se considerar slo las ontologas formales, que tienen


semnticas que describen el significado de una forma precisa. Es decir, que la semntica
no se refiere a opiniones ni intuiciones, y que las mquinas y las personas deben
interpretarla de una misma forma. En definitiva, una semntica formal usa la lgica de

- 23 -
CAPITULO 2 ESTADO DEL ARTE

primer orden o un subconjunto de ella (como las lgicas descriptivas). Es indispensable


disponer de una semntica formal para implementar sistemas de inferencia o de
razonamiento automtico (sin intervencin humana). Son varias las utilidades del
razonamiento automtico:

Se puede comprobar automticamente si una ontologa es consistente con el


conocimiento del dominio de inters que representa.

Se puede comprobar automticamente si las relaciones entre las clases


corresponden a los propsitos de la ontologa y se pueden detectar relaciones
espurias.

Permite clasificar automticamente las instancias en clases.

Las ontologas son una herramienta para compartir informacin 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 informacin.

Por lo general, el aspecto que toman consiste en una forma jerrquica de


trminos que representan los conceptos bsicos de un determinado dominio.

Figura 2.8 Las ontologas establecen redes semnticas

Las ontologas han sido utilizadas en diferentes reas de las ciencias de la


computacin, tales como inteligencia artificial, representacin del conocimiento,
procesamiento del lenguaje natural, Web Semntica e ingeniera del software, entre

- 24 -
CAPITULO 2 ESTADO DEL ARTE

otras. Por lo tanto, es razonable que haya una cierta divergencia entre sus mltiples
definiciones. A pesar de que una ontologa pueda tomar una gran variedad de formas,
necesariamente incluir un vocabulario de trminos, alguna especificacin de su
significado y una indicacin de cmo los conceptos se interrelacionan, lo cual impone
una estructura sobre el dominio y restringe las posibles interpretaciones de los trminos
(Uschold, 1999).

Las ontologas tienen los siguientes componentes que servirn para representar
el conocimiento de algn dominio (Gruber, 1993b, citado por Samper):

Conceptos: son las ideas bsicas que se intentan formalizar. Pueden ser clases
de objetos, mtodos, planes, estrategias, procesos de razonamiento, etc.

Relaciones: representan las interacciones y enlaces entre los conceptos del


dominio. Suelen formar la taxonoma del dominio.

Funciones: son un tipo concreto de relacin donde se identifica un elemento


mediante el clculo de una funcin que considera varios elementos de la
ontologa.

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 ontologa. Permiten junto al mecanismo de la
herencia de conceptos, inferir conocimiento que no est indicado explcitamente
en la taxonoma de conceptos.

En el mundo de las ontologas 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
tcnicas (provenientes de la IA o de la ingeniera del software o de bases de datos) que
permiten modelar una ontologa. Ahora bien, hay que destacar que el modelo slo se
podr considerar una ontologa si contiene un modelo de conocimiento consensuado y
compartido por la comunidad de inters.

En breve, un acuerdo con respecto a una ontologa comn es una garanta de


consistencia, pero no de completitud, con respecto a las bsquedas y aserciones,
usando el vocabulario definido en la ontologa. (Viegas et al., 1999)

Independientemente de la definicin adoptada, es importante entender que las


ontologas son empleadas para describir una gran variedad de datos y modelos.
Normalmente, las ontologas en el sentido dado por Gruber parten de taxonomas
previas. Ms adelante se explican las diferencias entre stas y aqullas.

2.3.5.1 Elementosdeunaontologa

Antes de continuar con la seccin de ontologas, se definirn algunos conceptos


para facilitar al lector la comprensin de los siguientes apartados.

- 25 -
CAPITULO 2 ESTADO DEL ARTE

Clases: representan los conceptos que forman el mbito de la ontologa. Los


conceptos son las ideas bsicas que se intentan formalizar y son el elemento
principal de una ontologa. Por ejemplo, en una ontologa que representase la
estructura poltica de Espaa, "PartidoPoltico" y "ComunidadAutnoma"
podran ser clases de la ontologa.

Subclases. Cuando una clase A es la generalizacin de otra clase B, se dice que


B es subclase (hija) de A. Siguiendo el ejemplo de antes, PartidoSocial sera
subclase de PartidoPoltico. Responde afirmativamente a la pregunta Un
partido social es un partido poltico?

Clases Hermanas. Dos clases son hermanas si comparten la clase padre. Son
subclases de una misma clase. Las clases PartidoSocialy PartidoPopular
seran hermanas.

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


tambin elemento de la otra.

Propiedades: establecen relaciones entre conceptos de la ontologa. 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,
"Andaluca" es una instancia de la clase "ComunidadAutnoma" y "PSOE" es
una instancia de la clase "PartidoPoltico". Las clases se suelen organizar en una
jerarqua, donde las instancias de una subclase pertenecen a la clase. Por
ejemplo, podramos tener en nuestra ontologa la clase "localizacin" de la que
sera subclase "ComunidadAutnoma".

2.3.5.2 TiposdeOntologas

Las ontologas se pueden clasificar teniendo en cuenta diferentes criterios. En la


literatura pueden encontrarse muchas posibilidades. Veamos dos de ellas:

1. Segn el alcance de su aplicabilidad:

Ontologas de Dominio. Proporcionan el vocabulario necesario para


describir un dominio dado o subdominio, como la medicina, el trfico, el
sector mobiliario. Incluyen trminos 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 teoras, relaciones y


frmulas que regulan o rigen el dominio.

Ontologas Generales: Representan conceptos generales que no son


especficos de un dominio. Por ejemplo, ontologas sobre el tiempo, el
espacio, ontologas de conducta, de causalidad, etc.

Ontologas de Tareas. Proporcionan el vocabulario para describir


trminos involucrados en los procesos de resolucin 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, planificacin,
asignar, clasificar,).

2. Segn la granularidad de la conceptualizacin (cantidad y tipo de


conceptualizacin):

Terminolgicas: Especifican los trminos que son usados para


representar conocimiento en el universo de discurso. Suelen usarse para
unificar vocabulario en un dominio determinado (contenido lxico y no
semntico).

De informacin: Especifican la estructura de almacenamiento de bases


de datos. Ofrecen un marco para el almacenamiento estandarizado de
informacin (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 (trminos y semntica).

2.3.5.3 OntologasfrenteaTaxonomas

Una taxonoma es una clasificacin estricta de trminos de forma jerrquica,


usando la relacin padre-hijo (generalizacin, es-un, o tipo-de). Las taxonomas no
permiten definir atributos para los trminos.

Un ejemplo de taxonoma es la estructura de directorio de nuestro ordenador. Es


una jerarqua severa y estricta que slo establece relacin entre los nombres de los
directorios (vocabulario) y la estructura jerrquica.

Una ontologa es una taxonoma ampliada, donde adems de un vocabulario que


nos define el contenido de una estructura, podemos establecer informacin documental
a la propia jerarqua, establecer reglas, restricciones lgicas y definir axiomas que nos
hagan llegar a una meta como el razonamiento automtico o inferencia.

Segn Noy y MacGuinness (Noy y MacGuiness, 2001) hay tres propiedades que
una ontologa debe poseer para diferenciarla de una taxonoma o tesauro:

Estricta jerarqua de conceptos: toda instancia de una clase debe ser tambin

- 27 -
CAPITULO 2 ESTADO DEL ARTE

instancia de su clase padre. La organizacin de trminos debe seguir una


relacin de generalizacin.

Interpretacin 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 Lenguajesdeontologas

Existen multitud de lenguajes que permiten la representacin de ontologas: OIL


(Ontology Inference Layer), DAML (DARPA Agent Mark-Up Language), SHOE (Simple
HTML Ontology Extensin), TopicMaps, OCLM, Ontolingua, LOOM, CycL, etc. No
todos ellos permiten el mismo nivel de expresividad a la ontologa construida ni
tampoco ofrecen las mismas funcionalidades.

A la hora de elegir un lenguaje para la definicin de una ontologa deben tenerse


en
cuenta los siguientes aspectos:

El lenguaje debe poseer una sintaxis bien definida para poder leer con
facilidad la ontologa definida.
Debe tener una semntica bien definida para comprender perfectamente el
funcionamiento de la ontologa.
Debe tener suficiente expresividad para poder capturar varias ontologas.
Debe ser fcilmente mapeable desde/hacia otros lenguajes ontolgicos.
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 heterogneas 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 propsito de resolver
el problema de la heterogeneidad en los lenguajes de representacin del
conocimiento. Se trata de un lenguaje formal con notacin tipo Lisp para escribir
los axiomas en las definiciones de Ontolingua.

PIF (Process Interchange Format): Tiene el mismo propsito 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 organizacin y entre varias organizaciones.

- 28 -
CAPITULO 2 ESTADO DEL ARTE

2.3.5.4.1 Lenguajestradicionales

Los lenguajes de ontologas tradicionales se distinguen segn la forma en la que


se basan para representar el conocimiento: basado en frames, en lgica descriptiva,
predicados de primer orden y segundo orden, o los orientados a objetos.

A continuacin se exponen los ms representativos (Gmez-Prez, 2004):

Ontolingua (Ontolingua, 2004) fue desarrollado en 1992 por KSL


(Universidad de Standford), es un lenguaje de ontologas basado en KIF y en
Frame Ontology (FO) empleado en el Ontolingua Server. KIF permite
definir objetos, relaciones y funciones y utiliza predicados de lgica de
primer orden. Como KIF es un lenguaje no orientado a construir ontologas,
sino para intercambio de conocimiento, Ontolingua emplea FO para permitir
la descripcin de ontologas utilizando los paradigmas de frames, y con el
que empezaron a surgir trminos como clase, instancia o subclase. FO no
permita 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 representacin de conocimiento, y permite,
como otros sistemas basados en frames, clases, constantes, atributos, frames
e instancias que sirven de base de conocimiento. Tambin implementa una
interfaz para acceder al conocimiento al igual que funciones utilizadas para
acceder a travs 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 aadi un mdulo de mecanismos de lgica y una interfaz
para poder interactuar con el conocimiento. Una de las ventajas que tiene es
que es compatible con estndares 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
representacin de conceptos, taxonomas, 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
polimrficos, etc. Con Flogic se han creado de bases de datos hasta
ontologas y se puede combinar con otros programas de lgica para
interactuar con la informacin almacenada en la ontologa (Flogic, 2004).

- 29 -
CAPITULO 2 ESTADO DEL ARTE

2.3.5.4.2 LenguajesbasadosenestndaresyenWeb

Estos lenguajes fueron desarrollados especficamente para el desarrollo de


ontologas. 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 ms extensa que una base de conocimiento, es necesario el uso de
estndares que permitan implementar ontologas en este ambiente.

Los ms destacados son: el lenguaje RDF (Resource Description Framework)


que implementa un modelo bsico 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
semntica: OWL-Lite, OWL-DL y OWL-Full. Todos estos lenguajes se sustentan para su
formalizacin en el XML, metalenguaje que permite definir y validar los lenguajes de
etiquetado que se usan en la Web. Se va a ver la definicin y las caractersticas de los
ms destacados:

RDF y RDFS

RDF (Resource Description Framework, Marco de Descripcin de Recursos)


(RDF, 2004a; RDF, 2004b) fue desarrollado por el World Wide Web Consortium (W3C)
con el objetivo de especificar semntica, para los datos basados en XML, de una
manera interoperable y estandarizada. Su recomendacin por la W3C fue establecida el
10 de febrero de 2004, establece la sintaxis y estructura que permite la descripcin de
metadatos y permite que el significado sea asociado con los datos a travs de RDF
Schema (RDFS, 2004), el cual facilita la definicin de ontologas especficas de
dominio.

Se trata de una infraestructura que permite la interoperabilidad de metadatos


mediante el diseo de mecanismos que dan soporte a las convenciones comunes de
semntica, sintaxis y estructura. RDF hace uso de XML como sintaxis comn para el
intercambio y proceso de metadatos, proveyendo independencia, extensibilidad,
validacin, legibilidad humana, y la habilidad para representar estructuras complejas.
RDF explota estas caractersticas imponiendo a su vez, estructuras que permiten
expresividad semntica inequvoca. Provee adems un medio para publicar vocabularios
legibles por los humanos y capaces de ser procesados por las mquinas, y stos pueden
ser reutilizados, extendidos o refinados para adaptarlos a los diferentes dominios
especficos segn sus requerimientos.

Aunque suela decirse que RDF es un lenguaje, resulta ms 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, caractersticas o


representan una relacin 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 especfico. 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


construccin bsica en RDF. Un conjunto de dichas tripletas es llamado grafo RDF, el
cual define la sintaxis abstracta de RDF. Esto puede ilustrarse a travs 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 trmino grafo).

Figura 2.9 Diagrama de nodos y arcos.

En la figura 2.10 se incluye la representacin grfica de tripletas de RDF.

Figura 2.10 Representacin de tripletas RDF.

Ntese que las propiedades (direccin, ciudad, cdigo 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 (Rodrguez,
2005).

- 31 -
CAPITULO 2 ESTADO DEL ARTE

RDF se puede emplear en cualquier campo: no se asocia a ningn dominio en


particular. Cada organizacin o persona puede definir su propio vocabulario mediante lo
que se conoce como RDF Schema (esquema de RDF), que se define en funcin de las
sentencias RDF (Abin, 2005).

RDF Schema permite la definicin de jerarquas de clases (relacin de subclase


y subpropiedad) de objetos y propiedades (relaciones binarias) y permite la creacin de
restricciones (rango y dominio). Este esquema se aproxima ms al concepto de
ontologa ya que se dispone de relaciones diseadas para especificar la jerarqua de la
taxonoma de conceptos que define un conocimiento.

RDF(S) funciona como un modelo semntico de datos capaz de permitir


preguntas referentes a su contenido y no a la estructura del documento.

RDF Schema incluye tres clases principales (Abin, 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 pginas web, organizaciones,


personas, bsquedas 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 jerarquas 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 ms clases. Y el dominio se emplea para
establecer que un recurso con una cierta propiedad es instancia de una o ms
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 descripcin en lengua natural de un


recurso. Por ejemplo, <rdfs:comment> Las neveras enfran lo que se
introduce en ellas </rdfs:comment>.

rdfs:label proporciona una versin legible para los humanos del nombre
del recurso. P.e.,<rdfs:label>Frigorfico</rdfs:label>.

rdfs:seeAlso especifica un recurso que proporciona informacin

- 32 -
CAPITULO 2 ESTADO DEL ARTE

adicional sobre el recurso principal. P.e., <rdfs:seeAlso>


http://www.vocabulario.es/aparatos </rdfs:seeAlso>

rdfs:isDefinedBy indica cul es el recurso donde se define el recurso


principal. Es una subpropiedad de rdfs:seeAlso.

La Web semntica no sera 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 vlidas solo para algunas
clases.

No se pueden representar algunas caractersticas de las propiedades, como que


una propiedad sea: transitiva, simtrica, 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 ms 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 lgica 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 acta 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 semntica.

Los usuarios de RDF y RDFS conforme utilizaban estos lenguajes para expresar
los metadatos de sus recursos, observaban que ambos lenguajes describan un conjunto
escaso de facilidades para expresar estos metadatos. Por ejemplo, no podan hacer uso
de datatypes del XMLSchema (XMLS, 2001), no podan hacer enumeraciones etc. La
comunidad de usuarios vieron en RDF una herramienta para expresar sus recursos, pero
tambin lamentaban que no existiesen facilidades para permitir la inferencia sobre las
descripciones RDF. Tena que surgir una evolucin 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 clasificacin 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, tambin tiene sus diferencias, la principal
es que se trata de un lenguaje que se aleja de los ideales de frames de OIL, para
acercarse ms a una base de lenguajes de lgica descriptiva.

Por lo tanto, DAML+OIL es un lenguaje que tiene una semntica sencilla y bien
definida, y que nos ofrece ms expresiones sofisticadas para las descripciones de
clasificaciones y propiedades de los recursos que las que ofreca RDF y RDFS.

DAML+OIL es la evolucin de RDFS, en el que se redefinen muchas de sus


descripciones y se aaden muchas otras para mejorar el lenguaje y aportar propiedades
y mecanismos para que el lenguaje defina ontologas que despus pueden ser empleadas
por sistemas de razonamiento para poder inferir sobre la informacin.

Sin una semntica bien definida y procedimientos de inferencia, los Agentes no


sern capaces de procesar la informacin de forma consistente. Como una plataforma
desde donde manejar las ontologas, DAML + OIL es bastante til, segn sus propios
autores, es una alternativa firme a RDF Schema u otros.

OWL

OWL (Ontology Web Language) (OWL, 2004) surge del W3C como la bsqueda
de un
lenguaje de especificacin de ontologas que sirva como estndar para todos los
investigadores de la Web semntica. 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 diferencindose en algunas.

OWL tambin es una extensin de RDFS y emplea el modelo de tripletas de


RDF. En parte, es un RDFS mejorado, que mantiene una buena relacin 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 inclusin, disyuncin y la equivalencia, se pueden
definir restricciones de cardinalidad en propiedades o dar propiedades sobre las
relaciones (transitiva, simetra) as como permitir clases enumeradas.

Como pude verse, OWL tiene mucha ms capacidad expresiva que RDFS.
Adems, OWL facilita la importacin y exportacin de clases: incluye propiedades
como sameAs, equivalentClass, equivalentProperty, differentFrom, etc. Por ejemplo,
equivalentClass permite establecer que dos clases de distintas ontologas sean
equivalentes (p.e. onto1:Persona y onto2:SerHumano), esto significa, que cada
instancia de una clase ser tambin instancia de la otra clase, y viceversa. La capacidad
de expresar que dos clases son iguales resulta muy til cuando se integran o mezclan
ontologas y permite la interoperabilidad.

Una ontologa en OWL es una secuencia de axiomas, hechos y referencias a


otras ontologas, que se consideran incluidas en la ontologa. Las ontologas OWL son
documentos web, y pueden ser referenciados a travs de una URI.

- 34 -
CAPITULO 2 ESTADO DEL ARTE

OWL se decidi separar en tres niveles, atendiendo a su expresividad semntica:

OWL Lite: la versin ms simple para los programadores principiantes. Permite


la jerarqua de clasificacin y las restricciones simples.

OWL DL: esta versin 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 versin tambin incluye todo el vocabulario de OWL, pero
interpretado de forma ms amplia que en OWL DL, con la libertad
proporcionada por RDF, en este caso no hay limitaciones para explotar todo su
potencial. No tiene garantas computacionales.

OWL Full se considera la ms completa de todas y se supone una extensin de


DL que a su vez es una extensin de Lite, por lo que toda ontologa correcta en OWL
Lite es una ontologa correcta en OWL DL, y toda conclusin correcta en OWL Lite es
una conclusin correcta en OWL DL (pero no a la inversa). De la misma manera esto
tambin ocurre con OWL DL y OWL Full respectivamente.

Este lenguaje tambin posee funcionalidades de razonamiento para las


ontologas.

2.3.5.5 Metodologasylibrerasparaconstruccindeontologas

Construir una ontologa es un proceso compuesto por una serie de actividades


orientadas al desarrollo de la ontologa. Existen un conjunto de propuestas de
metodologas de construccin de ontologas, pero no hay un estndar para la creacin de
una ontologa. En general, las metodologas proporcionan un conjunto de directrices que
indican cmo hay que llevar a cabo las actividades identificadas en el proceso de
desarrollo, qu tcnicas son las ms apropiadas en cada actividad y qu produce cada
una de ellas.

Hay dos mtodos principales que nos permite diferenciar dos tipos de ontologas
segn su construccin:

1) Kactus: es un mtodo de construccin de ontologas que se basa en tomar una


base de conocimiento y, a partir de sta, determinar y conceptualizar cuales son
los trminos y relaciones ms importantes que representaran a la ontologa.
(Bernaras, 1996, citado por Samper 2005).

2) Sensus: es un mtodo que representa a las ontologas construidas a partir de una


rama de una ontologa ms general y que es especializada para obtener una
ontologa nueva (Swartout, 1997, citado por Samper, 2005). Es decir, consiste en
crear ontologas especficas de dominio a partir de una ontologa ms general.

Las principales metodologas para construir ontologas desde cero son:

- 35 -
CAPITULO 2 ESTADO DEL ARTE

La metodologa TOVE, que se utiliz para construir la ontologa TOVE


(acerca de los procesos de modelado de una empresa) (Fox, 1995; Gruninger
et al., 1995; Gruninger, 1996). Est basada en la identificacin de escenarios
y la formulacin de preguntas de competencia (Competency Questions),
extraccin de conceptos y relaciones relevantes y la formalizacin en Lgica
de Primer Orden.

La metodologa ENTERPRISE, que se utilize para construir la ontologa


ENTERPRISE (tambin sobre procesos de modelado de empresa) (Uschold
et al., 1995; Uschold 1996; Uschold et al., 1996). Se basa en identificar el
propsito para posteriormente construir, evaluar y documentar las ontologas.

METHONTOLOGY (Gmez-Prez et al., 1996), que se utilz para constuir,


entre otras, la ontologa Chemicals (que es sobre los elementos de qumicos
de la tabla peridica) Es recomendada por FIPA (FIPA, 2004), y lleva a cabo
su cometido mediante las tareas de especificacin, adquisicin de
conocimiento, conceptualizacin, integracin, implementacin, evaluacin y
documentacin de las ontologas (comentadas anteriormente).

De las metodologas anteriores, la ms consensuada es METHONTOLOGY. A


continuacin se describen las etapas a travs de las cuales se construye una ontologa
segn esta metodologa:

Especificacin, donde se identifica el objetivo y el alcance de la ontologa. El


objetivo contesta a la pregunta " por qu es construida la ontologa? y el
alcance contesta la pregunta " cules son sus empleos intencionados y usuarios
finales?"

Conceptualizacin, donde se describe, en un modelo conceptual, la ontologa


que debera ser construida para llegar a la especificacin definida en el paso
anterior.

Formalizacin, donde se transforma la descripcin hallada en el paso anterior a


un modelo formal.

Implementacin, donde uno implementa la ontologa formalizada en un lenguaje


de representacin de conocimiento formal.

Mantenimiento, donde se modifica y se corrige la ontologa implementada.

Adems de las actividades anteriores, que se deben llevar a cabo en cada etapa
homnima, existen otras actividades que pueden ser realizadas durante todo el ciclo de
vida de la ontologa:

Adquisicin de conocimientos: se adquiere conocimiento sobre el dominio, ya


sea utilizando tcnicas de estimulacin en expertos de dominio, o haciendo
referencia a bibliografa relevante.

Documentacin: se describe en un documento y a lo largo de la implementacin

- 36 -
CAPITULO 2 ESTADO DEL ARTE

lo que se hizo, cmo se ha hecho y por qu se hizo.

Evaluacin: donde un tcnico juzga la ontologa.

Existe adems otra actividad que depende de la metodologa:

La reutilizacin: que reutilicen la ontologa otros, tanto como sea posible. La


mayora de las metodologas le dan a esta actividad el nombre de integracin.

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 ontologa, segn la
metodologa METHONTOLOGY.

Figura 2.11 Actividades del ciclo de vida del desarrollo de una ontologa

Existen aproximaciones que no proponen ningn modelo de ciclo de vida


(Gmez-Prez 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 Ingeniera y Adquisicin Ontolgica (Goble, 2002)

Los mtodos y metodologas no han sido creados nicamente para construir


ontologas desde cero. Cuando se reutiliza una ontologa puede suceder que sta est
implementada en un lenguaje con un paradigma de representacin de conocimiento
subyacente, diferente a las convenciones de representacin usadas por la ontologa que
la reutiliza, que tenga diferentes enfoques etc. Para resolver algunos de estos problemas
METHONTOLOGY incluye un mtodo de reingeniera basado en las actividades de
reingeniera inversa, consistente en obtener el modelo conceptual desde el cdigo de
implementacin y posteriormente la actividad de reestructuracin del modelo
obtenido. (Gmez-Prez et al., 2004)

Para este proyecto se ha utilizado la metodologa METHONTOLOGY, y como


gua para llevar a cabo las distintas etapas de creacin de la ontologa 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 ontologa.


En este punto se establece hasta dnde 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 reutilizacin de ontologas existentes.


Dada la naturaleza de la Web semntica es importante conocer si existe ya
alguna ontologa de mbito similar o incluso del mismo mbito que nos
concierne. Cualquier ontologa ganar mucha calidad si se relaciona con otras.

Enumeracin de los trminos ms importantes.


En este apartado se trata de enumerar los trminos ms importantes del dominio
en cuestin.
- 38 -
CAPITULO 2 ESTADO DEL ARTE

Definicin de las clases y su jerarqua.


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

Un proceso de desarrollo arriba-abajo. Definir primero los conceptos ms


generales e ir adentrndose en connceptos ms concretos.

Un proceso de desarrollo abajo-arriba. Comenzar con lo ms especfico e ir


generalizando.

Un proceso de desarrollo combinado. Primero se definen los conceptos ms


importantes, luego los generalizamos y especializamos apropiadamente.

Definir las propiedades de las clases.

Definir las propiedades ms concretamente.

Creacin de las Instancias.

- 39 -
CAPITULO 2 ESTADO DEL ARTE

2.3.5.6 HerramientasparalaconstruccindeOntologas

La principal herramienta para la construccin de una ontologa son los editores.


Los editores de ontologas soportan la definicin de jerarquas de conceptos, la
definicin de atributos o propiedades de los conceptos, y la definicin de axiomas y
restricciones. Los editores suelen ser desarrollados para un tipo de lenguaje especfico,
pero muchos de ellos incorporaron mdulos para soportar otros lenguajes de
especificacin 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).

Protg-2000 (Protg, 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 ontologas ms conocido. Sus capacidades grficas
facilitan la edicin de ontologas. Actualmente es uno de los editores de
ontologas ms usado por investigadores para desarrollar sus ontologas, ya que
es una herramienta que se actualiza con bastante regularidad y a la que se le
pueden aadir mdulos y plugins con nuevas funcionalidades, entre los que
destaca OWLViz, herramienta de visualizacin grfica de ontologas basada en
grafos. Permite que la ontologa desarrollada se exporte a los diferentes
lenguajes de especificacin ms empleados actualmente (RDF, OWL, etc.). La
ltima versin fue lanzada muy recientemente, v3.4, en marzo de 2009. El 26 de
Octubre de 2008 se lanz el editor de ontologas basado en web WebProtege
v0.5 alpha, cuyo objetivo principal es soportar el proceso de desarrollo de
ontologas colaborativas en entorno web.

- 40 -
CAPITULO 2 ESTADO DEL ARTE

Figura 2.13 El editor de ontologas Protg-OWL.

OilEd al igual que Protg-2000 es un editor de ontologas basado en Java, que


fue desarrollado en el contexto del proyecto europeo IST OntoKnowledge, por la
Universidad de Manchester. Es un editor de ontologas de libre acceso, que
permite al usuario construir ontologas usando OIL, y cuyo objetivo es ser un
medio completo de desarrollo de ontologas. El modelo de conocimiento de
OILEd es una extensin del sistema basado en marcos y, a diferencia de Protg-
2000, permite el uso de lenguajes de alta expresividad como DAML+OIL. Sin
embargo, no soporta el desarrollo de ontologa a gran escala ni el versionado, ni
la migracin e integracin de ontologas. 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 adems 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 grfica que soporta el desarrollo y mantenimiento


de ontologas. El modelo interno de ontologa en que se basa permite desarrollar
el dominio mediante el uso de clases, relaciones, axiomas, slots y atributos.
Se le pueden aadir nuevas funcionalidades tambin a travs 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 ms, se ha llegado a la


conclusin de que la ms recomendable es Protg. Es gratuito y de cdigo abierto; y
detrs 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 Protg-OWL (ver figura 2.13).

- 42 -
CAPITULO 2 ESTADO DEL ARTE

2.3.6. BasesdeConocimientofrenteaBasesdeDatos
Las bases de conocimiento (KM) son una evolucin de las bases de datos (BD)
tradicionales en un intento de plasmar elementos de conocimiento y la forma en que ste
debe ser utilizado. Adems 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 trminos y
relaciones (TBox), que puede se comparada al esquema de las BDs; y la parte de
instancias (ABox) o datos. Pero la semntica de esta parte difiere de la interpretacin
semntica de la instancia de los datos de las BDs. En una BD, la aunsencia de
informacin se interpreta como informacin negativa, sin embargo la aunsencia de
informacin en ABox solo indica una falta de conocimiento. Sirvase como ejemplo que
la nica asercin 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 ms ingredientes. El conocimiento en las BDs se considera como
mundo cerrado, que asume que un hecho es falso a no ser que haya sido
explcitamente 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. Sistemasdealmacenamiento

Una de las herramientas ms desarrolladas por los investigadores de la Web


Semntica han sido los sistemas de almacenamiento de ontologas. Mediante estos
sistemas es posible mantener las ontologas en bases de datos e ir aadiendo nueva
informacin, y con la ayuda de razonadores probar la consistencia de la ontologa. La
mayora de los sistemas de almacenamiento estn orientados a descripciones de
conceptos escritas en RDF, aunque algunas han ido actualizndose a los ltimos
lenguajes de especificacin.

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 aadir y eliminar
informacin 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 almacenarn las ontologas, 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 ontologas DAML
+ OIL como RDF.

- 43 -
CAPITULO 2 ESTADO DEL ARTE

Jena (Jena, 2007) es una coleccin de herramientas desarrollado por Hewlett-


Packard para la Web semntica. La primera versin tena capacidades de
razonamiento muy limitadas y principalmente daba soporte a RDF. En la
segunda versin ya se incluy una API de Java para trabajar con ontologas y
soporte del lenguaje OWL. En la actualidad Jena2 incluye:

ARP: un parser de RDF.


API de RDF.
API de ontologas 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 ontologa desde la aplicacin web.

2.3.8. Razonadores

Los razonadores son una de las herramientas ms importantes utilizadas con las
ontologas, sirven para realizar inferencia (deducir informacin adicional), a travs 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 Lgica Descriptiva, asocia dos mecanismos


internos en su entendimiento del conocimiento. El primero denominado TBox (caja
terminolgica) y un segundo llamado ABox (caja de aserciones). En general, la TBox
contiene sentencias describiendo conceptos jerrquicos (p.e., relaciones entre
conceptos) mientras la ABox contiene sentencias ground indicando a donde pertenecen
los individuos en la jerarqua (p.e., relaciones entre individuos y conceptos). Esta
separacin es puramente operativa, ya que estas distinciones permite a un razonador de
lgica descriptiva operar de mejor forma.

La figura 2.14 muestra la arquitectura de un Sistema Terminolgico (marco de


investigacin de la lgica 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 informacin sobre el dominio organizada utilizando una
jerarqua 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 lgica descriptiva que se est utilizando y finalmente el interfaz que
permite la interoperabilidad con el Sistema Terminolgico.

- 44 -
CAPITULO 2 ESTADO DEL ARTE

Figura 2.15 Arquitectura de un Sistema Terminolgico (Horrocks, 2001).

Los principales razonadores o sistemas de inferencia basados en lgica


descriptiva actualmente son:

RACER (Renamed ABox and Concept Expression Reasoner) (RACER, 2008)


desarrollado por Ralf Mller y Volker Haarslev en 1999, pero que ha sido
renovado peridicamente hasta la fecha (la ltima versin comercial es la 1.9.0 y
se lanzar una nueva versin Racer-Pro 2.0 durante el 2009). Es un razonador
diseado para la Web Semntica. Permite la inferencia tanto en conceptos como
en instancias, soporta ontologas 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 Protg tanto para comprobar la consistencia de la ontologa, 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 ontologas,
clasificar la taxonoma y contestar a un subconjunto de consultas RDQL
(conocido como consultas a ABox en terminologa 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 lgica descriptiva deben de poseer la suficiente


expresividad para poder permitir que el conjunto de constructores que forman parte de
los lenguajes de ontologas sean soportados, y poder permitir ambos tipos de inferencia,
tanto de clasificacin como de chequeo de instancias.

- 45 -
CAPITULO 2 ESTADO DEL ARTE

2.3.9. Lenguajesdeconsulta
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
aproximacin totalmente declarativa. Debido a esto, solo se pueden hacer
consultas sobre la informacin 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.

Adems de la desventaja de no permitir realizar ninguna inferencia, la


utilizacin 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
integracin 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 aadidos nuevos propios.
Algunas de las funcionalidades ms importantes que ofrece SeRQL son:

Transformacin 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 devolucin de tablas con los posibles
valores que pueden tomar las variables en nuestra consulta (Select, comn al
resto de lenguajes), y devolviendo el resultado en la forma de subgrafo que
nosotros le sugerimos, almacenando la informacin 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 dilogo 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


descripcin 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 ontologa dql.daml. Esta ontologa 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 actualizacin del lenguaje anterior (DQL). En este caso, se


trata de un lenguaje formal y protocolo para conducir el dilogo 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 estndar, y para ello tiene en cuenta una serie de
factores dentro de la Web Semntica:

La previsin de que incluir muchos tipos de servicios peticin-respuesta


con acceso a muchos tipos de informacin representados en muchos
formatos. Por lo que se debe lograr manejar esta heterogeneidad.
El hecho de que algunos servidores contengan solo informacin parcial
sobre algn tpico y por tanto sern incapaces de manejar o dar respuesta
a ciertos tipos de requerimientos. Se pretende que los propios protocolos
de consulta puedan proveer algn medio de transferencia de resultados
parciales.
La idea de que una consulta o requerimiento especificada en un lenguaje
de la Web Semntica necesita dar soporte a requerimientos que no
incluyan una especificacin 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 bsqueda. 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 Semntica, los lenguajes
declarativos usados para representar en la Web tenga una semntica
definida formal y lgica. 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 haban encontrado en los dems 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 caracterstica ms destacable de este lenguaje es que posee construcciones


propias especficas para las relaciones semnticas 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 ms fcil recuperar informacin 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 bsquedas a travs de una gran variedad de
informacin como puede ser datos personales, redes sociales y metadatos sobre
recursos digitales como msica e imgenes. SPARQL tambin proporciona un
camino de integracin sobre recursos diferentes.

Es un lenguaje para hacer bsquedas en fuentes de datos donde los datos se


almacenan en RDF o, al menos, pueden ser vistos como RDF. Es muy rpido y
permite obtener resultados de las bsquedas como grafos de RDF.
Permite:

Extraer informacin en diversas formas, incluyendo URIs.


Extraer subgrafos RDF.
Construir nuevos grafos RDF basados en la informacin de los grafos
consultados.

- 48 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

3. METODOLOGAYPLANDETRABAJO

3.1. Planificacinygestindelproyecto

La gestin de un proyecto de software comienza con un conjunto de actividades


que en su totalidad se denominan planificacin del proyecto. Antes de empezar con el
desarrollo de un proyecto se debe estimar el trabajo que habr que realizar, los recursos
que se requerirn 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
ingeniera 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 planificacin 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 planificacin es la estimacin. Esta actividad


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

La estimacin comienza con una descripcin del mbito del proyecto. Luego, se
descompone el problema en un conjunto de problemas ms pequeos, y se estima el
esfuerzo para realizar cada uno de stos empleando datos histricos y la experiencia
como guas (Pressman, 2007).

En la primera parte de esta seccin se muestra el proceso de planificacin


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 Martn, 2002).

Y en la segunda parte se realiza la asignacin de los recursos requeridos para el


desarrollo de este proyecto, as como la estimacin del esfuerzo y el dinero que va a
costar realizar el proyecto.

- 49 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

3.1.1. Definicinderecursos
Los recursos necesarios para completar el esfuerzo de desarrollo de este
proyecto se van a determinar en dos grandes categoras de los recursos de ingeniera del
software: el personal y el entorno de desarrollo (hardware y herramientas de software).

3.1.1.1 Recursoshumanos

Teniendo en cuenta la naturaleza de este proyecto, al tratarse de un proyecto


acadmico y a la vez desarrollado para una empresa, los perfiles de los miembros del
grupo de trabajo que intervendrn sern los siguientes:

Director y Codirector de proyecto.

El director (Dr. Javier Samper Zapater) tendr el papel de tutor acadmico.


Como tutor acadmico se ocupar del contenido acadmico del proyecto.
Aconsejar sobre las reas a desarrollar, las herramientas y tcnicas a emplear,
as como asegurarse de que se est elaborando la documentacin adecuada.

La Codirectora (D Mara Jos Nez) desempear la funcin de manager


en la empresa. Dirigir el proyecto en el sentido ms general. Se preocupar
del progreso global, asegurndose de que se estn consiguiendo los objetivos
parciales que se han propuesto.

Jefe de proyecto (D. Miguel ngel Abin)

Sus principales funciones sern 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,
asegurndose de que se cumple el tiempo y requisitos establecidos.

Analista y Programador (Mouna Ziouziou)

En el desarrollo de todo sistema informtico los principales componentes son el


anlisis y el diseo del sistema. El anlisis 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 diseo. El diseo es el proceso utilizado para
definir cmo se va a desarrollar el sistema, qu mdulos lo formarn y cmo de
comunicarn entre s, cul ser la estructura del cdigo a implementar, etc.

El analista ser el responsable de mantener entrevistas y sesiones de trabajo con


los responsables de la organizacin y usuarios para establecer los requisitos del
sistema, y en base a esto realizar un anlisis y diseo coherentes del sistema a
desarrollar.

El programador ser el encargado de la implementacin del cdigo del sistema


basndose en el diseo realizado previamente; as como de realizar la carga
inicial de datos y las pruebas del sistema.

- 50 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

3.1.1.2 Recursosdelentorno

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


entorno de ingeniera 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 prctica de la ingeniera del
software. Para este proyecto, el hardware que se emplear ser:

Ordenador porttil Pentium Centrino.


Ordenador porttil 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 ontologa:

Editor de ontologas (Protg 2000).


Razonador (Racer Pro, Pellet,...).

- Para el desarrollo de la aplicacin:

Interfaz para el modelado del sistema en UML (Enterprise Architect,


Poseidn...).
Entorno de desarrollo (Eclipse, Netbeans,...).
API para trabajar con ontologas (Jena, Sesame...).

- Para documentar el proyecto:

Procesador de texto (MS Office 2007).


Herramienta de planificacin para desarrollar un cronograma con la
planificacin temporal del proyecto (MS Project).

Ms adelante se ver la estimacin de los costes asignados a los elementos


hardware y software que se han mencionado en este apartado.


3.1.2. Planificacintemporal

La planificacin temporal consiste en desarrollar un plan para la realizacin del


proyecto. Tiene dos funciones: clarificar el orden de las tareas, y estimar el tiempo
necesario para llevarlas a cabo (Dawson y Martn, 2002).

La estimacin del esfuerzo necesario se realiza en base a la experiencia


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

- 51 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

El recurso Analista/Programador tendr una dedicacin de 4 horas al da, cinco


das a la semana. Teniendo en cuenta que el proyecto tendr una duracin de
aproximadamente un ao, la disponibilidad inicial es de 960 horas.

Durante toda la duracin del proyecto se contar con la ayuda del director y del
jefe de proyecto, por lo que tambin habr que tener en cuenta las horas que
stos le dediquen.

Descomposicin del proyecto en subtareas

El primer paso en el proceso de planificacin es la divisin 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 ms se descomponga el problema ms correcta ser luego la estimacin.


Aunque no conviene perder mucho tiempo intentando hacer una planificacin lo ms
exacta posible. Se trata de alcanzar un equilibrio que solucione las necesidades del
proyecto.

Antes de descomponer el proyecto conviene establecer el propsito 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 descomposicin que se realiza se identifican 7 tareas que se


corresponden con los objetivos principales. A continuacin se describen brevemente la
funcionalidad y las subtareas de cada una de estas actividades:

1) Puesta al da bibliogrfica

Se trata de recopilar y analizar la informacin disponible sobre el tema del


proyecto. Se divide en dos fases: bsqueda y revisin (Dawson y Martn, 2002).

La bsqueda bibliogrfica consiste en: buscar, ordenar, gestionar y asimilar


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

La revisin bibliogrfica consiste en: comprender lo ledo y extraer las ideas


principales para el propsito de nuestro proyecto.

2) Anlisis y desarrollo de la ontologa.

Esta tarea constituye el primero de los objetivos principales de este proyecto,


que es la obtencin de una ontologa del dominio del mueble que est basada en
el estndar funStep. Incluye todo el proceso de definicin de la ontologa
(adquisicin de conocimiento, especificacin, conceptualizacin, formalizacin
e implementacin), la creacin de instancias y la prueba de la ontologa. El
resultado de todo esto constituye una base de conocimiento a la cual acceder la

- 52 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

aplicacin de bsqueda que se va a desarrollar. Se descompone en las siguientes


actividades:

Anlisis de requisitos. Se delimitarn los requisitos para el desarrollo de


la ontologa.

Anlisis 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 ontologa a desarrollar. Pues uno
de los requisitos establecidos para la creacin de la ontologa es basarse
en el estndar internacional funStep.

Adquisicin de conocimiento. Esta fase consistir en mantener entrevistas


con expertos en el sector y recopilar informacin de las distintas fuentes
disponibles (normas, catlogos, libros, enciclopedias, etc.).

Definicin de la ontologa. Se definirn los conceptos y relaciones


siguiendo una metodologa de desarrollo de ontologas. Se crearn
instancias y se probar la ontologa.

3) Anlisis del sistema.

Se recopilarn y se interpretarn los requisitos para el desarrollo del buscador.


Se determinarn los casos de uso del sistema, as como el comportamiento y la
funcionalidad del mismo. Finalmente, se analizarn los componentes que va a
necesitar la interfaz de usuario para manejar de forma sencilla los diferentes
casos de uso establecidos.

4) Diseo del sistema.

Se descompondr el sistema en los subsistemas que sern necesarios para


construir e implementar los diferentes casos de uso definidos en la fase de
anlisis.

5) Implementacin

Se realizar la codificacin de las estructuras definidas en las fases de anlisis y


diseo 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 redaccin de la memoria.


Se intenta dejar reflejado todo el trabajo realizado.

- 53 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Figura 3.1Descomposicin del proyecto en tareas


- 54 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Estimacin 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 Duracin estimada


Puesta al da bibliogrfica 240 horas
Anlisis y desarrollo de la ontologa 260 horas
Anlisis del sistema 80 horas
Diseo del sistema 8 horas
Implementacin 100 horas
Pruebas del sistema 20 horas
Completar la memoria 160 horas
Total 1020 horas

Tabla 3.1 Estimacin de tiempos del proyecto

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

Recurso Nombre Horas


Director del proyecto Javier Samper 32
Codirectora del proyecto M Jos Nez 20
Jefe de Proyecto Miguel ngel Abin 96
Analista/Programador Mouna Ziouziou 872
Total 1020

Tabla 3.2 Estimacin de tiempos del proyecto

Identificacin de hitos

El siguiente paso en el proceso de planificacin del proyecto es la identificacin


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 Martn, 2002).

Para identificar los hitos hay que centrarse en la divisin 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:

Finalizacin de la investigacin bibliogrfica (hito 1; H1)


Fin de creacin de la ontologa de muebles y afines (hito2; H2)
Finalizar el desarrollo de la aplicacin de bsqueda (hito3;H3)

- 55 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Finalizacin de la escritura de la memoria (hito4; H4)

A la hora de realizar la planificacin temporal de un proyecto hay que tener en


cuenta la ordenacin temporal de las actividades ya que habr algunas tareas que
necesitarn de los resultados obtenidos en fases anteriores en el tiempo o de
determinados recursos que en ese momento estarn siendo utilizados por otras
actividades. La planificacin por lo tanto, se encargar de definir el orden correcto de
ejecucin y la duracin asociada a cada tarea.

3.1.2.1 DiagramadeGantt

En la figura 3.2 se muestra el diagrama de Gantt que representa la planificacin


temporal de este proyecto. El eje de abscisas se usa para la distribucin del tiempo,
representa el calendario de ejecucin 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 duracin estimada de la actividad.

- 56 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Figura 3.2 Diagrama de Gantt

- 57 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

3.2. Estimacindecostesdelproyecto
La realizacin 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 (adquisicin de documentacin,
comidas, o ciertos gastos de representacin).

Los costes indirectos se entienden como aquellos que la empresa debe ingresar a
travs de los proyectos que realice y en los cuales sta incurre, realice o no proyectos.
Se conocen tambin como los costes generales, tales como: alquiler y amortizacin del
inmueble, costes de suministros, de limpieza, mensajera, costes laborales asociados a
personal no productivo del proyecto (administracin, directivos, etc.).

A pesar de que en un proyecto acadmico pierde importancia el proceso de


estimacin de costes ya que el propsito buscado no es obtener beneficios econmicos,
se va a realizar igualmente puesto que es una buena prctica para la realizacin de
futuros proyectos.

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


pero lo viable es: el uso de tcnicas de descomposicin y la utilizacin de uno o ms
modelos empricos para estimacin de costo y esfuerzo. Las tcnicas de descomposicin
asumen un enfoque de divide y vencers respecto de la estimacin del proyecto de
software. Al descomponer un proyecto en funciones principales y actividades de
ingeniera del software relacionadas, las estimaciones de costes y esfuerzo se pueden
hacer en forma escalonada. Los modelos de estimacin emprica sirven para completar
las tcnicas de descomposicin y ofrecer un enfoque de estimacin potencialmente
valioso por su propio derecho (Pressman, 2007).

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


estimacin mediante una tcnica de descomposicin basada en el proceso, para estimar
el esfuerzo requerido, y en consecuencia, el coste del proyecto. Y posteriormente, una
estimacin basada en el modelo emprico COCOMO II (Constructive Cost Model,
Modelo Constructivo de Costos), que calcula el esfuerzo y el coste del desarrollo del
software en funcin del tamao del programa expresado en lneas de cdigo (LDC).


3.2.1. CosteLaboral
El coste laboral lo constituyen los gastos relacionados con el trabajo realizado
por las personas fsicas, y viene dado por el nmero de horas trabajadas junto con la
categora 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 tambin 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 categoras
participantes en este proyecto.
- 58 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

CATEGORA 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 categora

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 tcnicas existentes.
En el siguiente apartado se realiza esta estimacin utilizando la tcnica de
descomposicin basada en el proceso.

3.2.1.1 Tcnicabasadaenelproceso

La tcnica ms comn para estimar un proyecto es basar la estimacin 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 estimacin de horas calculadas en el apartado anterior


de Planificacin Temporal y los costes por horas arriba indicados la estimacin de coste
del personal la siguiente:

Categora Horas Coste por hora Total


Director de Proyecto 32 80 2.560
Codirector 20 70 1.400
Jefe de Proyecto 96 60 5.760
Analista/Programador 872 40 34.880
Total 1020 42,35 43.200

Tabla 3.4 Costes de personal


Una vez calculados los costes de personal, se va a proceder a estimar los costes
materiales. stos corresponden a los gastos de material informtico tanto software
como hardware, gastos de viajes, gastos de representacin y otros gastos como por
ejemplo de material de oficina.

Subcontrataciones

No se ha necesitado de ninguna subcontratacin para llevar a cabo el


proyecto.

- 59 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Material y equipo

Teniendo en cuenta los recursos de entorno que se van a emplear


citados en el apartado de Asignacin de recursos - los costes estimados son los
siguientes:

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

Tabla 3.5 Costes de material y equipo

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


anterior.

Viajes y estancias

No se ha realizado ningn viaje para el desarrollo del proyecto.

Otros costes

No se ha definido ningn 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 aadir a la suma de estos costes un 10% ms 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 estimacin de costes para este proyecto asciende a la


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

- 60 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

3.2.1.2 ElmodeloCOCOMO2

El COCOMO (Constructive Cost Model) es un modelo emprico para estimar el


esfuerzo, la calendarizacin y los costos de un proyecto informtico.

Se elige el modelo COCOMO para estimar los costes de este proyecto por las
siguientes razones:

1. Est bien documentado, es de dominio pblico y lo apoyan el dominio pblico y


las herramientas comerciales.

2. Se ha utilizado y evaluado muy ampliamente.

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

COCOMO II es una evolucin del modelo de estimacin COCOMO original, el


cual se convirti en uno de los modelos de estimacin de costo de software ms
ampliamente utilizados y estudiados en la industria (Boehm, 1996; Boehm, 2000).
Actualmente deriv a COCOMO 2000, en el que nos basaremos en la estimacin
realizada a continuacin. ste considera diferentes enfoques para el desarrollo de
software como el de construccin de prototipos, el desarrollo por composicin de
componentes, la utilizacin 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 ms detalladas se llevan a cabo
despus de definirse la arquitectura del sistema.

Se va a emplear el nivel postarquitectnico ya que hace una estimacin


razonablemente precisa del tamao del software. Se utilizan 17 atributos que reflejan la
capacidad del personal, el producto y las caractersticas del proyecto, para refinar el
clculo del esfuerzo final.

Los costes laborales (en persona-mes) se obtienen mediante la siguiente


expresin:

P = A x ESLOCB x M + PMm

A continuacin se muestra cmo se calculan los distintos parmetros de los que


consta la expresin:

A: Este parmetro viene dado por Boehm, que propone que sea de 2,5.

ESLOC: Lneas de cdigo nuevo, se calcula de la siguiente manera:

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

- 61 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Siendo:

ASLOC: Miles de lneas de cdigo reutilizables que deben


modificarse.

AA: Factor que refleja los costos de valoracin inicial acerca de la


posible reutilizacin del software (0-8).

SU: Factor que se basa en el costo de comprensin del software (10-


50)

DM: Porcentaje de modificacin del diseo

CM: Porcentaje de cdigo 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 tamao 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 + Resolucin de la arquitectura +


Cohesin del equipo + Madurez del proceso) / 100 + 1,01

Precedentes: Refleja la experiencia previa de la organizacin con este


tipo de proyectos. Muy bajo significa sin experiencia previa, y extraalto
significa que la organizacin est completamente familiarizada con este
dominio de aplicacin. 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.

Resolucin de la arquitectura: Refleja la amplitud del anlisis de riesgos


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

Cohesin 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 difciles, y extraalto significa un equipo integrado y
efectivo sin problemas de comunicacin. En este caso no existe
informacin ya que se crea un nuevo equipo valor Nominal (3).

- 62 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

Madurez del proceso: Refleja la madurez del proceso de la organizacin.

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 reutilizacin requerida (RUSE), la
dificultad de la plataforma (PDIF), la capacidad del personal (PERS), la
experiencia del personal (PREX), la calendarizacin (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
postarquitectnico 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 crtica, pero s que se debe asegurar un buen
funcionamiento del sistema.

DATA: Tamao de la base de datos. En este caso, la base de datos


se generar de forma automtica a partir del modelo ontolgico
creado. Contendr tanto el modelo ontolgico 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 mdulos del sistema. Mide si el


software desarrollado emplea un cdigo con mltiples estructuras
de control, clculos, operaciones dependientes de dispositivos
En este caso aunque las operaciones no dependan de dispositivos,
construir una ontologa donde se mantenga la coherencia y la
consistencia puede resultar un cdigo algo complejo. Adems de
la complejidad de la estructura RDF, consultas y libreras
utilizadas. Por ello se le da valor alto a este atributo.

2. Atributos de la computadora:

TIME: Limitaciones en el tiempo de ejecucin. Los tiempos de


proceso no son demasiado elevados por lo que se toma un valor
nominal.

- 63 -
CAPITULO 3 METODOLOGA Y PLAN DE TRABAJO

STOR: Restricciones de memoria principal. Debido a que se


requiere que toda la informacin est almacenada en memoria se
ocupa bastante espacio en memoria principal por lo que se aplica
valor alto.

PVOL: Volatilidad de la mquina virtual. La mquina virtual se


considera el conjunto de hardware y software que el producto
emplea para desarrollar sus funciones. Dado que la mayora de las
herramientas utilizadas son estndares que an se encuentran en
estado de borrador, se aplica un alto grado de volatilidad.

3. Atributos de personal:

ACAP: Capacitacin de los analistas. Atributo que sirve para medir la


capacidad que poseen los analistas implicados en el proyecto para el
anlisis, 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 tena un
nivel bajo al comenzar el desarrollo del producto.

PCAP: Capacitacin 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 programacin a lo largo de la
carrera.

LTEX: Experiencia en el lenguaje de programacin. Si el lenguaje


empleado en la implementacin del producto es desconocido para
el personal, el desarrollo se hace ms complejo. En este caso, se
tiene experiencia adquirida a lo largo de la carrera en el lenguaje
de programacin empleado para el desarrollo del Interfaz, sin
embargo la experiencia en lenguajes de ontologas 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 planificacin. 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 METODOLOGA 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 numrico asociado que se debe aplicar como
multiplicador:

Atributo Valor Valor Multiplicativo


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

Tabla 3.6 Valores de los atributos y valores multiplicativos asociados

El factor multiplicativo se obtiene tras la multiplicacin 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


cdigo se genera de forma automtica. El esfuerzo requerido (PMm) se calcula
de forma independiente utilizando la siguiente frmula y despus sumndola al
esfuerzo calculado para el cdigo desarrollado manualmente.

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

Siendo:

ASLOC: Nmero de lneas de cdigo reutilizable que deben modificarse.

AT: Porcentaje del cdigo total del sistema que se genera


automticamente.

ATPROD: Nivel de productividad para este tipo de produccin de


cdigo.

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 METODOLOGA 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 aadir 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 aade un 10% ms 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 INGENIERA

4. PROCESODEINGENIERA

4.1 Introduccin

En el desarrollo de este proyecto se han llevado a cabo dos tareas de naturalezas
bien distintas, cada una de las cuales requiere un anlisis, un diseo y una
implementacin.

Creacin de una ontologa del dominio del mueble y afines, que clasifica y
define los trminos de la industria del mueble y afines, basndose en el
estndar funStep.

Desarrollo de un interfaz que permita al usuario realizar bsquedas de


muebles en la base de conocimiento creada.

En esta seccin se expondr en primer lugar todo el proceso seguido para la


creacin de la Ontologa funStep siguiendo el ciclo de vida segn la metodologa
METHONTOLOGY (Gomez-Prez et al., 1996) explicada en el apartado Metodologas
y libreras de ontologas del Estado del arte; y en segundo lugar, las fases de anlisis y
diseo de la aplicacin de bsqueda.

4.2 OntologafunStep.Ciclodevida.
La primera tarea en el desarrollo del proyecto ha sido la realizacin de una
ontologa que cubriera el mbito del mueble y afines, incorporando modelos y
definiciones del estndar internacional funStep.

Para llevar a cabo la realizacin de cualquier ontologa, se debe tener en cuenta


la naturaleza de sta. Siempre considerando que cualquier elemento de la ontologa es
un recurso o concepto y mientras se analiza y disea no se est haciendo otra cosa que
crear conceptos. Cualquiera de estos elementos ha de servir como un recurso para
cualquier otro agente semntico. 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
ontologa ser descrito.

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


requisitos establecidos para la creacin de la ontologa; y en segundo lugar, se van a
exponer las distintas etapas seguidas para la definicin de la ontologa, que se
corresponden con el ciclo de vida de creacin de una ontologa segn la metodologa
METHONTOLOGY (Gmez-Prez et al., 1996), y se detallan los pasos seguidos para
llevar a cabo cada una de las etapas de esta metodologa (explicadas en el apartado de
Metodologas y libreras para construccin de ontologas del Estado del arte).

- 67 -
CAPITULO 4 PROCESO DE INGENIERA

4.2.1. EspecificacindeRequisitos

Los requisitos establecidos para la creacin de la ontologa de muebles y afines


son los siguientes:

El prototipo creado debe incorporar los conceptos ms usados en la


industria del mueble y afines.

El prototipo debe de realizar una transcripcin semntica de parte del


modelo lgico funStep, mediante la creacin 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 ontologa cubre un dominio ya
establecido por la industria y funStep. Este dominio responde al acuerdo
de muchas partes fabricantes, consumidores, tcnicos - , y se puede
encontrar con versiones futuras que nos lleven a cambios en el modelo
de datos ontolgico para poder volver a cubrir todo el dominio de la
aplicacin. En segundo lugar, en el futuro se podra extender la ontologa
vg., aadiendo propiedades o conceptos no definidos en el modelo
ontolgico actual y que, por tanto, deberan aadirlos los programadores
que manejen el prototipo.

El prototipo debe ser modular. De esta forma facilita la comprensin a


futuros programadores que lo manejen y de modo que una modificacin
en el mismo sea fcil de gestionar.

Como buena base de conocimientos, el prototipo tendr que ser


adecuadamente documentado, para que el conocimiento, adems de ser
reconocido por la mquina, lo sea tambin para las personas.

El idioma utilizado ser el ingls debido a los socios internacionales que


trabajan en funStep.

Hay que tener en cuenta que la Web Semntica es una de las reas de
conocimiento en mayor expansin, los estndares son bastante nuevos y aunque
comienzan a tener amplia acogida en la actualidad, es cierto que todava pueden
cambiar de una manera considerable. Es por ello que se tendr en cuenta la naturaleza
de la solucin y la seleccin de las herramientas para su realizacin.

Tambin se tendr en cuenta que la ontologa ser usada en un futuro para incluir
un volumen de datos considerable, por lo cual deber ser compacta en cuanto a su
extensin en disco.

- 68 -
CAPITULO 4 PROCESO DE INGENIERA

4.2.2. AnlisisdelModelodeDatosfunStep

Uno de los requisitos enumerados anteriormente es basarse en el estndar ISO


funStep para la realizacin de la ontologa. Bsicamente, se realizar una especie de
transcripcin semntica del modelo de datos funStep utilizado en el desarrollo de la
herramienta de generacin de catlogos Cadef (descrita en el segundo captulo).

En un futuro prximo se pretende enlazar, a travs de la herramienta Cadef, los


productos de un catlogo funStep a los conceptos de la ontologa, identificando de esta
manera cada producto con el tipo de mueble que es, y en consecuencia, se le asignaran
las propiedades correspondientes, a las que se podrn asignar valores. De esta manera,
se conseguir que el Cadef genere catlogos XML con las propiedades definidas en la
ontologa asignadas a los productos. Posteriormente, se parsearan los catlogos de
XML a RDF. Y con esto, lo que se estar consiguiendo es identificar con una URI a
cada elemento de nuestro catlogo, convirtindolo en un recurso, lo cual permitir su
localizacin. Y en consecuencia, la aplicacin de bsqueda que se desarrolla en este
proyecto podr cargar los catlogos generados (en OWL) y acceder a ellos resolviendo
las consultas de los usuarios.

La figura 4.1 muestra cmo se enlaza un producto de un catlogo en Cadef a un


concepto (clase) de la ontologa.

Figura 4.1 Implantacin actual de la herramienta Cadef.

- 69 -
CAPITULO 4 PROCESO DE INGENIERA

Se analizar el modelo de datos considerando en todo momento el alcance de la


ontologa que se va a crear, es decir, se pensar qu tipo de informacin se quiere
almacenar en la base de conocimientos, de modo que sea posible realizar las consultas
que se desea poder realizar.

El estndar ISO 10303-236 o funStep para catalogacin de mobiliario y diseo


de interiores, abarca el siguiente mbito:

1) Informacin de datos de catalogacin.


2) Representacin de la forma del producto.
3) Informacin parametrizada de datos de catalogacin.
4) Diseo interior de mobiliario.

Se pueden encontrar los detalles de cada parte en la documentacin de funStep


adjuntada en el CD que acompaa 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 ontologa, tales como descripcin
geomtrica, apariencia visual del producto, etc.

A continuacin se va a analizar cada una de las partes del modelo que son de
nuestro inters:

Catalogacin. Lgicamente esta parte es la ms importante puesto que en la


ontologa se desea representar toda la informacin relacionada con los productos
de un catlogo de muebles. Ver Anexo II (Data catalog.xml). Dentro de esta
parte se diferenciar entre:

Organisation. Entidad que almacena toda la informacin sobre una


empresa y los empleados que trabajan en ella, as como la informacin
de los productos ofrecidos por dicha empresa. Se aprovecharn las clases
y los atributos que interesen para conseguir el alcance que se que se
desea que tenga la ontologa.

Catalog structure. Se analizan las clases que representan la informacin


de un catlogo de muebles funStep y la representacin correspondiente
en la ontologa.

Figura 4.2 Estructura de un catlogo de datos

- 70 -
CAPITULO 4 PROCESO DE INGENIERA

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 Asignacin de propiedades

De la parte del modelo de datos correspondiente a la informacin relacionada


con la catalogacin de productos se destacan las siguientes entidades:

Organisation (Organizacin)
Product_class (Clase de producto)
Product_class_relationship (Clase de relacin con producto)
Class_category_association (Clase de asociacin de una categora de
especificacin con una clase de producto)
Specification_category (Categora de especificacin)
Specification (Especificacin)
Product_specification (Especificacin de producto)

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

- 71 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.4 Diagrama de informacin detallada sobre Organisation

De esta parte se trunca toda la informacin 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 (Organizacin) que representar
en nuestro modelo a los distintos agentes de la cadena de valor (proveedores, fabricantes
y comercios), y la clase Address (Direccin), que contiene toda la informacin de
contacto de una empresa.

Las entidades que representan la informacin de los productos de un catlogo y


las relaciones entre ellas se muestran en la figura 4.5.

- 72 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.5 Diagrama de Product_class y sus relaciones

- 73 -
CAPITULO 4 PROCESO DE INGENIERA

En la siguiente figura, se muestra un ejemplo representativo que ayuda a


entender la informacin que representa cada clase.

Figura 4.6 Ejemplo de configuracin detallada de un producto

El cdigo generado en XML sera:

Observando el ejemplo anterior, nos damos cuenta de que la clase Product_class


(PC) representa tanto catlogos como productos de un catlogo. Se utiliza el atributo
level_type para diferenciarlos. Y Product_relationship relaciona una PC con otra. Esto
en el modelo semntico, se traducira a conceptos distintos: Catalog (Catlogo) y
Product (Producto). Y de este ltimo colgara el concepto PieceOfFurnitture (Mueble).

Las relaciones se corresponden con las propiedades en la ontologa.

La clase Specification_category (SC) representa las categoras de especificacin

- 74 -
CAPITULO 4 PROCESO DE INGENIERA

en los catlogos 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 ontologa se


analizarn dos tipos:

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

Propiedades especficas de un tipo de mueble. Se investigarn caractersticas


especficas 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
representacin semntica.

Tras este anlisis, se obtienen las siguientes equivalencias entre las entidades del
modelo de catalogacin funStep y los elementos de la ontologa que se quiere construir:

Modelo funStep Ontologa


Product_class Conceptos (clases)
Specification_category Propiedades
Specification Valores de las propiedades
Product_specification Instancias

Tabla 4.1 Correspondencia de la Ontologa con el modelo de datos

En la seccin posterior de Construccin de la Ontologa se vern con ms detalle


las decisiones tomadas para representar toda esta informacin en la ontologa.

Otra parte que se tuvo en cuenta a la hora de transformar los elementos del
modelo de datos funStep al modelo semntico formal es la de Propiedades de producto.
La informacin 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 sera por ejemplo el precio si se quiere
tener precios diferentes para diferentes pases. Otra propiedad dependiente de contexto
podra ser el tamao del producto basado en los diversos sistemas de medida, por
ejemplo: pulgadas, cm., mm., etc.

Una propiedad independiente del contexto debera ser un valor fijo relacionado
con el producto que el propietario del catlogo quiera aadir a la informacin de
producto. Un posible ejemplo sera tener un lema (slogan) de venta especfico para
cada producto.

- 75 -
CAPITULO 4 PROCESO DE INGENIERA

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 INGENIERA

Todas las caractersticas que nos interesen sobre un producto se traducirn en la


ontologa 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 Construccin de la
Ontologa se vern las decisiones tomadas para representar los distintos tipos de
propiedades.

4.2.3. AdquisicindeConocimientos

Como se vio en el apartado Metodologas y libreras de ontologas del Estado del


arte, la fase de Adquisicin de conocimientos se realiza durante todo el ciclo de vida
de la ontologa.

A continuacin, se describen las principales fuentes de informacin que fueron


consideradas para adquirir conocimiento en el dominio que cubrir nuestra ontologa:

1) Normas de mobiliario:

ISO funStep: ISO 10303-236 Sistemas de automatizacin industrial e


integracin representacin e intercambio de los datos de Producto
Parte 236: Protocolo de aplicacin: Catlogo de muebles y diseo 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. MOISS Y CUNAS BALANCN


DE USO DOMSTICO. PARTE 1: REQUISITOS DE SEGURIDAD.

UNE-EN 13150:2001 MESAS DE LABORATORIO. DIMENSIONES,


REQUISITOS DE SEGURIDAD Y MTODOS DE ENSAYO.

UNE-EN 1727:1998 MOBILIARIO DOMSTICO. MUEBLES


CONTENEDORES. REQUISITOS DE SEGURIDAD Y MTODOS DE
ENSAYO.

UNE-EN 1728:2001 MOBILIARIO DOMSTICO. ASIENTOS.


MTODOS DE ENSAYO PARA LA DETERMINACIN DE LA
RESISTENCIA Y DE LA DURABILIDAD.

UNE-EN 1730:2000 MOBILIARIO DOMSTICO. MESAS.


MTODOS DE ENSAYO PARA LA DETERMINACIN DE LA
RESISTENCIA, LA DURABILIDAD Y LA ESTABILIDAD

UNE-EN 581-1:1998 MOBILIARIO DE EXTERIORES. ASIENTOS Y


MESAS DE USO DOMSTICO, PBLICO Y DE CAMPING. PARTE
1: REQUISITOS GENERALES DE SEGURIDAD.

- 77 -
CAPITULO 4 PROCESO DE INGENIERA

UNE-EN 716-1:1996 MUEBLES. CUNAS Y CUNAS PLEGABLES DE


USO DOMSTICO PARA NIOS. 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


DOMSTICO PARA NIOS. PARTE 1: REQUISITOS DE
SEGURIDAD. (ISO 9221-1, MODIFICADA).

UNE-ENV 12520:2000 MOBILIARIO DOMSTICO. ASIENTOS.


REQUISITOS MECNICOS Y ESTRUCTURALES DE SEGURIDAD.

UNE-ENV 1729-1:2002 MOBILIARIO. SILLAS Y MESAS PARA


CENTROS DE ENSEANZA. PARTE 1: DIMENSIONES
FUNCIONALES.

UNE-ENV 581-2:2000 MOBILIARIO DE EXTERIOR. ASIENTOS Y


MESAS DE USO DOMSTICO, PBLICO Y DE CAMPING. PARTE
2: REQUISITOS DE SEGURIDAD MECNICA Y MTODOS 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) Catlogos de muebles (tcnicos y de comerciales). Se han consultado catlogos


de diferentes sectores de mobiliario:

Oficinas (ej.: Catlogo de mobiliario de oficina de Federico Giner)


Infantil y juvenil (ej.: Lneas Taller de Muebles)
Sofs (ej.: Tapigroup, Capdell, Koo International)
Cocinas (ej.: Block Cocinas)
Ms.

4) Diccionarios y enciclopedias:

Diccionario de la RAE
Mara Moliner
Webster (ltima edicin)
Collins English Dictionary & Thesaurus
The Encyclopedia of Furniture: Third Edition - Completely Revised
Wikipedia

Considerando el tema de la integracin de otras ontologas, comentado en el


apartado de Metodologas y libreras de ontologas del Estado del arte, se investigaron
ontologas relacionadas con muebles y afines, pero solamente se encontraron
taxonomas de alcance muy limitado (sillas de oficina, p.ej.). Con lo cual, se analizarn

- 78 -
CAPITULO 4 PROCESO DE INGENIERA

dichas taxonomas, identificando cada uno de los conceptos clasificados y descubriendo


el proceso de construccin de las mismas. Y posteriormente, se ampliarn con nuevos
conceptos (trminos de muebles, sus componentes y algunos accesorios) para conseguir
cubrir el dominio de nuestra ontologa.
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. EspecificacindelaOntologa

La Especificacin es la primera actividad en el desarrollo de una ontologa. Es la


fase donde se identifican el objetivo y el alcance de la misma.

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


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

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


bsicas:

Para qu se usar la ontologa?


Para qu tipos de preguntas la informacin en la ontologa deber proveer
respuestas?
Quin usar y mantendr la ontologa?

Las respuestas a estas preguntas pueden cambiar durante el proceso de diseo de


la ontologa, pero en cualquier momento ayudarn a limitar el alcance del modelo.

La ontologa construida ser usada principalmente para realizar bsquedas de


muebles basadas en una serie de especificaciones indicadas por el usuario, y poder
consultar informacin relacionada con el mueble buscado. Por lo tanto, ser un
servicio enfocado hacia el cliente final y tambin hacia el comercio.

Servir tambin, combinada con las herramientas de anotacin semntica


desarrolladas en el proyecto europeo ATHENA (Advanced Technologies for
Interoperability of Heterogeneous Enterprise Networks and their Applications), para
anotar semnticamente imgenes, dibujos y diseos de muebles, ya procedan de
catlogos de fabricantes o distribuidores o de recursos de la web.

En nuestra ontologa figurarn conceptos que describen diferentes tipos de


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

A continuacin se listan los tipos de consultas que se desean realizar sobre la


ontologa:

- 79 -
CAPITULO 4 PROCESO DE INGENIERA

Bsqueda de un mueble por:

Fabricante
Tipo de mueble
Estilo
Distribuidor (geogrficamente)/quin y dnde encontrarlo
Material
Color
Tamao
Estilo
Precio. Bsqueda por rango de precio
Dimensiones (Alto, Ancho, Profundo)

Cul es el precio de un mueble?

Buscar una composicin por tipos de muebles que la componen

Una vez especificado el dominio de la ontologa y limitado el alcance de la


misma, se debe pensar en los trminos y las propiedades relacionados con el dominio de
inters. Por ejemplo, trminos importantes relativos a los muebles incluirn:
composicin, fabricante, material, color, estilo, precio, etc. Inicialmente es
importante obtener una lista integral de trminos sin preocuparse del recubrimiento
entre los conceptos que representan, relaciones entre los trminos, o cualquier propiedad
que los conceptos puedan tener, o si los conceptos son clases o slots.

4.2.5. Decisionesdediseo

Antes de pasar a describir el proceso de construccin de la ontologa, se


comentarn en este apartado las decisiones tomadas y sus argumentaciones, al igual que
algunos aspectos que se tuvieron en cuenta en la especificacin de la ontologa.

Como ya se ha explicado en la parte de metodologas del estado del arte, no


existe una simple y correcta metodologa de diseo de ontologas. Para el desarrollo de
nuestra ontologa nos hemos basado en una gua para definicin de ontologas propuesta
por Natalya F. Noy and Deborah L. McGuinness.

La primera decisin que se tuvo que tomar para el desarrollo de la ontologa fue
el lenguaje de marcado para expresarla. Se opt por el lenguaje OWL frente a RDFS ya
que es mucho ms expresivo, adems de que facilita la importacin y exportacin de
clases: incluye propiedades como sameAs, equivalentClass, equivalentProperty,
differentFrom, etc. La propiedad equivalentClass por ejemplo, permite expresar que dos
clases de ontologas distintas son equivalentes, lo que significa que cada instancia de
una clase ser tambin instancia de la otra, y viceversa. La capacidad de expresar que
dos entidades son iguales resulta muy til cuando se integran o se mezclan ontologas, y
permite la interoperabilidad.

Dentro del lenguaje OWL, tenemos que decidir entre los tres sublenguajes: OWL-
Lite, OWL-DL y OWL-Full. Se descarta desde un principio OWL-Lite ya que es la
versin ms incompleta, solo permite la jerarqua simple y restricciones simples.

- 80 -
CAPITULO 4 PROCESO DE INGENIERA

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
podra 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 decisin. Por mltiples motivos, se decidi que fuera OWL-DL:

Es decidible. Se puede analizar en toda su extensin por una mquina.


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 ontologa definida de esta manera.

Es el estndar en ontologas que se ha establecido y est auspiciado por la W3C.

Recordemos que la ontologa ser creada teniendo en cuenta el modelo de datos


del estndar ISO funStep.

En la seccin de Anlisis del modelo de datos funStep, se realiz un estudio del


esquema conceptual, destacando aquellas partes que nos interesan. Veamos ahora
cmo se tradujeron los diferentes elementos de inters del esquema conceptual a modelo
semntico formal:

La entidades del modelo de datos se transforman en clases y/o individuales


segn criterio y establecimiento de su jerarqua.

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


individuales o como subclases [Cec02]. El uso de clases es
semnticamente ms rico y hace que la ontologa se pueda extender ms
fcilmente.

Los atributos de algunas entidades se transformarn en propiedades. Pasos a


seguir:

a) Estas propiedades podrn ser de dos tipos: propiedades objeto


(ObjectProperty) o propiedades de tipos de datos
(DatatypeProperty), lo cual determinar el rango de valores que
pueden tomar.

i. Propiedades objeto son usadas para relacionar un recurso a


otro recurso.
ii. Propiedades de tipos de datos nicamente relacionan un
recurso a un rdfs:literal o a un tipo de datos perteneciente
a XML Schema.

b) Se estudiar segn criterios dados la conveniencia de restringir


estas propiedades globalmente: Rango y Dominio.

- 81 -
CAPITULO 4 PROCESO DE INGENIERA

i. Ms 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 cuantificacin generalmente.

c) Definicin de caractersticas de las propiedades: Transitivas,


Inversas, Simtricas.

i. Hay que tener en cuenta que las caractersticas de


transitividad o simtra solo podrn ser aplicadas en
propiedades de tipo objeto (relacionan dos recursos).

d) Inclusin de dicha propiedad en una jerarqua de propiedades


(eleccin de superpropiedad(es)) que ayudar en la aplicacin de
posibles mtodos de inferencia.

Atendiendo al alcance de nuestra ontologa, las entidades del modelo de datos


que necesitamos mapear son las siguientes:

Organisation (Organizacin). Queremos tener informacin sobre el fabricante de


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

Address (Direccin). Nos interesa conocer informacin de contacto de un


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

Product_class (Clase de prodcuto). Como vimos en el apartado de anlisis del


modelo de datos funStep, esta clase representa tanto un catlogo como un
producto. Por lo tanto, en la ontologa crearemos dos conceptos nuevos:
Catlogo y Producto, y la relacin entre ellos (Catalog hasProduct Product)
ser una propiedad de tipo no funcional, es decir, que un catlogo tiene varios
productos.

En cuanto a la parte Propiedades de producto se representar mediante


propiedades asignadas a la clase Producto. Vimos en el anlisis del modelo que en
funStep existen dos tipos de propiedades de producto: las dependientes del contexto y
las independientes del contexto. Estas propiedades sern representadas en la ontologa
mediante dos tipos de propiedades respectivamente: propiedades objeto
(ObjectProperty) y propiedades de tipo de dato (DatatypeProperty).

Para la informacin de localizacin de una empresa (comercio o fabricante de


muebles) se consideraron dos cosas:

La reutilizacin de ontologas ya existentes que definan los conceptos


correspondientes a los atributos de la clase Address. Esta solucin no fue

- 82 -
CAPITULO 4 PROCESO DE INGENIERA

llevada a cabo por dos motivos: No se ha encontrado una ontologa que


defina un dominio que cubra todos los atributos que tenemos en Address.
Y porque nuestro dominio est muy bien definido y queramos que
tuviera todas las clases necesarias.

La creacin de una ontologa que defina el subdominio de Direccin.


Esta opcin tambin 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 cmo se relacionan entre ellos en la ontologa:

Figura 4.9 Esquema de los conceptos mapeados a la ontologa

Las clases generadas a partir del modelo de datos son aquellas que permitirn
almacenar la informacin que se quiere obtener sobre los mueble. El resto de las clases
de la ontologia sern las corresponsientes a trminos de muebles, componentes de
muebles y algunos accesorios.

En el apartado de Construccin de la ontologa se vern un poco los detalles


sobre cmo se han ido desarrollando los distintos pasos de creacin de la ontologa, y
algunas decisiones tomadas.

- 83 -
CAPITULO 4 PROCESO DE INGENIERA

4.2.6. ConstruccindelaOntologa
En este apartado se van a exponer los pasos seguidos para la construccin de la
ontologa (Noy y McGuinness, 2005).

Para construir la ontologa se eligi como plataforma de desarrollo el editor


Protg por una serie de razones:

1) Ofrece un entorno amigable para la realizacin de ontologas y una gran


cantidad de documentacin que ayuda al aprendizaje de la herramienta como a la
utilizacin de la misma durante la implementacin.

2) Es el ms expandido. Se actualiza a menudo.

3) Permite integrar funcionalidades fcilmente mediante plugins.

Se utiliz ms concretamente el plugin Protg-OWL (Matthew Horridge et al.,


2004) que viene instalado por defecto en el programa. Este plugin ofrece muchas
singularidades para la generacin de ontologas con el lenguaje de marcado OWL. El
programa y el plugin estn desarrollados y mantenidos por la Universidad de Stanford y
son de libre distribucin.

Pasemos ahora a detallar los pasos correspondientes a la creacin de la ontologa


que se enumeraron en el apartado de Metodologas y libreras de ontologas del Estado
del arte.

1) Definir las clases y la jerarqua de clases

La taxonoma 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 Protg de
la figura 4.9.

El nivel superior (top level) est formado por los conceptos ms 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 jerarqua (bottom level)
son las ms especficas, como: Mesa de comedor (Dining Table), Mesita de noche
(Bedside Table), Mesa de cocina (Kitchen Table), etc.

Se ha conseguido establecer una taxonoma bastante detallada, que clasifica


bsicamente todos los tipos de muebles existentes actualmente en el mercado. En la
figura 4.9 se pueden ver los dos primeros niveles de la jerarqua (para ver la taxonoma
completa dirigirse al archivo FurnitureOntology.owl que se encuentra en el CD que
acompaa esta memoria).

- 84 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.10 Diferentes niveles de la taxonoma de muebles

- 85 -
CAPITULO 4 PROCESO DE INGENIERA

Obtenida la taxonoma de muebles, hubo que detallar los conceptos de los


elementos que componen los diferentes tipos de muebles (por lo menos los ms
generales). Para ello, se han tenido que tomar ciertas decisiones de diseo. Es
fundamental obtener una buena clasificacin de estos trminos puesto que
posteriormente, la definicin de los conceptos de muebles se har a partir de su
composicin. La siguiente figura muestra una captura de Protg con la jerarqua de
conceptos de componentes de muebles que se han definido:

Figura 4.11 Jerarqua de Componentes de muebles

2) Definir las propiedades de las clases

Las clases definidas en la taxonoma de muebles son clases aisladas, es decir, se


corresponden con trminos de objetos que tienen existencia independiente. Estas clases
no proveen suficiente informacin para responder a las preguntas de competencia que
determinan el alcance de nuestra ontologa (expuestas en el apartado anterior de
Especificacin de la Ontologa).

Se necesita definir trminos que describan la estructura interna de los conceptos.


Estos trminos sern clases que se relacionan con las clases definidas anteriormente, a
travs 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 continuacin se muestran ejemplos de cada
tipo.

- 86 -
CAPITULO 4 PROCESO DE INGENIERA

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. Adems 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_colchn) 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 bsicas
que se han seguido para definir ambos:

Cuando se define un dominio o rango de una propiedad, se debe


encontrar las clases o clase ms 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 intil 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 INGENIERA

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 slo 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 tambin la instancia b con c, entonces se puede
inferir que a se relaciona con c a travs de la propiedad.

Simetra. Si una propiedad P es simtrica, y relaciona la instancia a con


b, significa que b tambin se relaciona con a a travs 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 INGENIERA

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
caractersticas 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 cdigo que muestra un ejemplo de la
definicin de la propiedad hasUnit, que especifica la unidad2 en la que se
expresa el precio de un producto.

<owl:FunctionalPropertyrdf:ID="hasUnit">
<rdfs:range>
<owl:DataRange>
<owl:oneOfrdf:parseType="Resource">
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Points</rdf:first>
<rdf:restrdf:parseType="Resource">
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
></rdf:first>
<rdf:restrdf: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/22rdf
syntaxs#nil">
</rdf:rest>
</rdf:rest>
</owl:oneOf>
</owl:DataRange>
</rdfs:range>
<rdfs:domainrdf:resource="#Price"/>
<rdf:type
rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
</owl:FunctionalProperty>

2 En los catlogos 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 INGENIERA

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 categoras principales:

Restricciones de cuantificador (quantifier restrictions)


Los cuantificadores usados son:

El cuantificador existencial (), que se puede leer como al menos


un, o algn3. Por ejemplo, la restriccin hasBase BedBase
establecida para la clase Bed, indica que toda instancia de Cama
debe tener al menos una base de cama (BedBase). Pero esta
restriccin sola, no significa que la propiedad hasBase no pueda
tomar valores de otro tipo de base, como por ejemplo Pedestal.
Por eso, necesitamos establecer otro axioma que restrinja eso.

El cuantificador universal (), que se puede leer como slo

3 En OWL se expresa como restriccin someValuesFrom

- 90 -
CAPITULO 4 PROCESO DE INGENIERA

(only4). Siguiendo con el ejemplo de antes, la restriccin


hasBase BedBase indica que una instancia de Cama se puede
relacionar a travs de la propiedad hasBase slo con
instancias de la clase BedBase. Esta restriccin 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 slo 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 asuncin 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 travs 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 cdigo generado por Protg 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
cdigo 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 cdigo, vemos que Stool es equivalente a Seat con unas

4 En OWL se expresa como restriccin allValuesFrom

- 91 -
CAPITULO 4 PROCESO DE INGENIERA

restricciones de las propiedades hasBase y hasSeat. La restriccin de hasBase establece


los valores que puede tomar esta propiedad de la clase Base. Y la restriccin 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:Classrdf:ID="Stool">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOfrdf:parseType="Collection">
<owl:Restriction>
<owl:onPropertyrdf:resource="#hasBase"/>
<owl:allValuesFrom>
<owl:Class>
<owl:unionOfrdf:parseType="Collection">
<owl:Classrdf:about="#CantileverFrame"/>
<owl:Classrdf:about="#Leg"/>
<owl:Classrdf:about="#Pedestal"/>
</owl:unionOf>
</owl:Class>
</owl:allValuesFrom>
</owl:Restriction>
<owl:Restriction>
<owl:onPropertyrdf:resource="#hasSeat"/>
<owl:cardinality
rdf:datatype="&xsd;int">1</owl:cardinality>
</owl:Restriction>
<owl:Classrdf:about="#Seat"/>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<owl:disjointWithrdf:resource="#Bench"/>
<owl:disjointWithrdf:resource="#Chair"/>
<owl:disjointWithrdf:resource="#Swing"/>
<owl:disjointWithrdf: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 restriccin 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 INGENIERA

Figura 4.16 Restriccin de tipo hasValue para la clase Sofa

4) Crear instancias

El ltimo paso consiste en crear instancias individuales de clases en la jerarqua.


La definicin 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 versin de la ontologa sin instancias de muebles.


Posteriormente, se crean las instancias de muebles, extradas de catlogos de
fabricantes, obteniendo as una base de conocimiento de prueba, sobre la cual se
realizarn consultas con el buscador.

- 93 -
CAPITULO 4 PROCESO DE INGENIERA

4.3 AplicacindeBsquedaWeb

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


una aplicacin web para realizar bsquedas dirigidas al sector mobiliario. Esta
aplicacin debe ser capaz de permitir a los usuarios realizar consultas complejas y
obtener resultados exactos, proporcionndoles un interfaz grfico amigable, sencillo y
rpido.

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


proyecto. Esta base de conocimiento est constituida por la Ontologa funStep de
muebles y afines con los conceptos y relaciones definidos, ms las instancias de
muebles introducidas. Ms adelante, en el apartado de Implementacin, se ver cmo se
implanta la ontologa en la aplicacin web y las herramientas utilizadas para acceder a
la informacin de la base de conocimiento cargada.

En este apartado se van a exponer las fases de anlisis y diseo del sistema
desarrollado.

4.3.1. FASEDEANLISIS

En esta fase se van a especificar los requisitos establecidos para la realizacin


del prototipo y se va a analizar el sistema a desarrollar.

La especificacin 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 especificacin de requisitos puede llevar a serios problemas en el
calendario de trabajo ya que se tendran 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 ms costoso realizar algn cambio en


los requisitos, por ejemplo, si se produce en la fase de implementacin se hace muy
costoso ya que habra que modificar la especificacin de requisitos, el anlisis, el diseo
y la implementacin tanto del mdulo afectado como de los mdulos que se comunican
con l. Sin embargo, si se produce en la fase de especificacin de requisitos su coste es
nfimo.

Con una buena especificacin de requisitos se proporcionar una visin global y


a la vez especfica del sistema a desarrollar, que ser coherente con los requisitos
establecidos por el cliente y servir como base para el diseo e implementacin del
sistema.

- 94 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.1.1.Especificacinderequisitos

El sistema a desarrollar es una aplicacin que permita a los usuarios realizar


bsquedas especficas de productos de la industria del mueble. El usuario deber poder
describir las caractersticas del mueble que busca a travs de un interfaz sencillo y
amigable, y el sistema deber permitir al usuario obtener informacin sobre los
productos disponibles en los catlogos de diferentes comercios y/o fabricantes.

El buscador desarrollado estar basado en tecnologa semntica 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 informacin 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 va web para que el usuario pueda hacer
uso de la aplicacin de bsqueda de la manera ms fcil y cmoda posible, a
travs de un navegador web.

El buscador desarrollado ha de hacer uso de un vocabulario comn (funStep), es


decir, de los conceptos y relaciones definidas en la ontologa 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 bsquedas que se desea poder realizar
son: buscar un mueble con unas caractersticas 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 ningn conocimiento sobre el sector del mueble, y por
ello, se desea poder hacer uso de un lenguaje sencillo y comn a la hora de
especificar las caractersticas deseadas en el mueble buscado.

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

Buscar un mueble por:

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

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


colectividades, etc.

Estilo: moderno, clsico, vanguardista, etc.

Material: madera, metal, plstico o cristal.

- 95 -
CAPITULO 4 PROCESO DE INGENIERA

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 fcil uso, intuitivo para el usuario.

Los resultados de la peticin deben obtenerse en poco tiempo.

- 96 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.1.2.Funcionalidadesdelsistema

Para definir las funcionalidades del sistema es necesario saber quin va a


utilizarlo. Teniendo en cuenta el tercer requisito establecido, se identifica un nico tipo
de actor que interacta con el sistema: cualquier usuario que accede a la aplicacin para
realizar bsquedas de informacin relacionada con el sector del mueble y afines. Podr
ser un cliente final o bien un comercio, pero la funcionalidad de la aplicacin ser la
misma para ambos.

Sabiendo quin va a utilizar el sistema, se puede pasar a definir las


funcionalidades que va a tener ste:

Ref. Funcin Categora


F1.1 Introducir caractersticas deseadas. Evidente
F1.2 Realizar bsqueda. Evidente
F1.3 Buscar mueble o composicin (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 composicin por ambiente o destino. Oculta
F1.15 Buscar composicin por tipo de muebles que la componen. Oculta
F1.16 Obtener detalles de un producto Evidente
F1.17 Mostrar informacin sobre el producto seleccionado. Oculta

Tabla 4.2.- Funciones del Sistema

- 97 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.1.3.Casosdeuso

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 diseado deber permitir al usuario introducir una serie de


caractersticas, que sern recogidas por la aplicacin para formular la consulta
correspondiente y devolver los resultados obtenidos. A continuacin, 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


genricos, por lo que se van a detallar a continuacin:

- 98 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.18 Caso de uso Buscar Muebles detallado.

Figura 4.19Caso de uso Buscar Composiciones detallado.

- 99 -
CAPITULO 4 PROCESO DE INGENIERA

El establecimiento de los casos de uso permite definir el sistema desde el punto


de vista funcional, antes de abordar su estructura interna. A continuacin 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

Propsito: Indicar el tipo de mueble que se desea buscar (mueble o


composicin).

Tipo: Principal

Descripcin: El usuario especifica el tipo de mueble que busca. El sistema


muestra el interfaz correspondiente al tipo de mueble
especificado.

Referencias: F1.1

Secuencia tpica de eventos:

Actor Sistema
1.- El usuario accede a la aplicacin
y desea buscar un producto.
2.- El usuario selecciona el tipo de
producto que desea buscar.
3.- Muestra el interfaz con las
propiedades correspondientes al
tipo de producto elegido por el
usuario.

Caso de uso: Realizar una bsqueda

Actores: Usuario

Propsito: Solicitar la bsqueda de un producto (mueble o composicin) con


unas caractersticas especificadas.

Tipo: Principal

Descripcin: El usuario pulsa el botn de bsqueda tras indicar las


caractersticas del producto buscado. El sistema devolver una
lista de instancias que cumplan con las caractersticas
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 INGENIERA

Secuencia tpica de eventos:

Actor Sistema
1.- El usuario selecciona las
caractersticas que desea en el
producto que busca.
2.- El usuario pulsa el botn de
bsqueda tras indicar las
caractersticas buscadas.
3.- Recoge del interfaz los valores
indicados de las propiedades.
4.- Genera y ejecuta la consulta
correspondiente.
5.- Devuelve una lista con las
instancias resultado de la consulta.

Caso de uso: Obtener detalles de un producto

Actores: Usuario

Propsito: Obtener informacin detallada sobre un producto especfico.

Tipo: Principal

Descripcin: El usuario selecciona un producto de la lista devuelta por el


sistema resultado de la bsqueda solicitando obtener informacin
detallada sobre un producto especfico. El sistema realiza las
consultas necesarias y muestra al usuario una serie de detalles
sobre el producto seleccionado, tales como descripcin,
fabricante, materiales, acabados y colores disponibles, etc.

Referencias: F1.16, F1.17.

Secuencia tpica de eventos:

Actor Sistema
1.- El usuario selecciona un producto
de la lista para obtener detalles.
2.- Genera y ejecuta la consulta
correspondiente.
3.-Muestra la informacin del
producto en el interfaz de usuario.

- 101 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.1.4.DiagramasdeActividad

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 continuacin se muestran los diagramas de actividad de nuestro sistema:

Figura 4.20 Diagrama de Actividad Especificar tipo mueble

- 102 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.21 Diagrama de Actividad Realizar Bsqueda

- 103 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.22 Diagrama de Actividad Obtener detalles

- 104 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.1.5.Anlisisdelinterfazdeusuario

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


ontologa. Se proporcionar una estructura de rbol con la jerarqua de productos
disponibles.

2) Buscar un producto genrico. El usuario tendr la eleccin de realizar una


bsqueda muy detallada o bien bsquedas ms genricas. Por ejemplo, puede
que no indique un tipo especfico de mueble, y quiera obtener la lista de todos
los productos de un comercio en concreto. Por ello, se proporcionar una
pantalla con propiedades genricas y con el botn de buscar.

3) Buscar un tipo de mueble especfico. El usuario podr elegir un tipo de mueble


especfico entre los diferentes tipos que existen. La jerarqua de clasificacin de
muebles de la ontologa es demasiado extensa y detallada, se proporcionar una
pantalla para los tipos de mueble definidos en el primer nivel de la jerarqua.
Segn el tipo de mueble elegido por el usuario se mostrar una pantalla u otra
con las propiedades especficas de cada tipo. Habr cuatro pantallas distintas
para:

Bsqueda de una Mesa (mesitas, mesas de comedor, escritorios, etc.)


Bsqueda de un Asiento (sillas, sillones, sofs, sillas de ruedas, etc.)
Bsqueda de un Mueble de almacenaje (armarios, vitrinas, cmodas, etc.)
Bsqueda de una Cama (individual, doble, de hospital, camillas, etc.)

4) Bsqueda de una composicin. Se proporcionar una pantalla distinta para la


bsqueda de composiciones ya que poseen propiedades propias como por
ejemplo ambiente o tipos de componentes.

- 105 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.2. FASEDEDISEO

En todo proyecto software es muy importante la fase de diseo, facilita la


descomposicin del sistema en subsistemas para construir e implementar los diferentes
casos de uso definidos en la fase de anlisis.

Existen varias tcnicas para realizar el diseo de un sistema software. La tcnica


elegida en este caso es la orientada a objetos. Es la tcnica ms utilizada en la
actualidad. Se realiza un diseo del sistema desde el punto de vista de la programacin
orientada a objetos, y tiene como elementos principales las clases y las relaciones entre
ellas. A diferencia de un diseo relacional, donde el diseo se realiza desde el punto de
vista de una base de datos relacional.

Se utilizar el estndar UML (Unified Modeling Language) para modelar el


sistema. ste estndar rene una coleccin de tcnicas que permiten especificar,
visualizar, construir y documentar los elementos del sistema.

4.3.2.1.DiseodelaAplicacin

En este apartado se expondrn los objetos definidos para el correcto


funcionamiento del sistema.

Una vez elegida la tcnica de diseo del sistema, se procede a definir los objetos
necesarios para el correcto funcionamiento de la aplicacin y las relaciones entre ellos.

Se ha diseado el sistema intentando separar lo que es propio de nuestra


aplicacin de las funcionalidades genricas que podran ser reutilizables en otros
proyectos relacionados con ontologas. 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 INGENIERA

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 aadir
escuchadores a los componentes. En esta clase se definirn todos los
componentes visuales del interfaz (paneles, botones, cajas de texto,
etc.). Contendr los mtodos del ciclo de vida de un applet, un
mtodo que se encargue de aadir escuchadores a los componentes y
todos los getters de los componentes visuales que permitirn
obtenerlos y manejarlos.

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


de usuario. Se relaciona con todas las dems clases del sistema,
actuando de puente entre las clase que contiene la definicin del
applet y el resto de clases. Contendr todos los mtodos que
implementan acciones de respuesta a eventos. Inicializa los
componentes del interfaz y realiza la llamada al mtodo que carga el
modelo de ontologa, y posteriormente al mtodo que construye un
rbol (JTree) con las clases de la ontologa que cuelgan de la clase

- 107 -
CAPITULO 4 PROCESO DE INGENIERA

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 ontologa y de acceder a este realizando peticiones y
operaciones:

Clase LoaderOntology. Implementa los mtodos de carga del


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

Clase ClientOntology. Esta clase contendr mtodos genricos que


extraen informacin de la ontologa y la devuelven al manejador para
mostrarla en el interfaz. Implementa funciones como
convertirOntologiaEnArbol(nombreRaiz), que convierte las clases de
la ontologa que cuelgan de la clase nombreRaiz en nodos de un
rbol en java. Esta funcionalidad podra resultar til en cualquier otro
proyecto, de modo que se desarrolla de manera genrica pudiendo ser
reutilizada en otros trabajos.

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


SPARQL con las bsquedas 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.Diagramadeclases

En la siguiente figura se muestra el diagrama que representa los objetos


definidos para el desarrollo de la aplicacin junto con las relaciones entre ellos. Se trata
de una versin reducida del diagrama de clases del sistema que contiene los atributos y
mtodos ms relevantes de cada clase (el diagrama de clases completo, con todos los
mtodos y atributos se puede ver en el fichero Aplicacin.eap que se encuentra en el
CD que acompaa esta memoria).

- 108 -
CAPITULO 4 PROCESO DE INGENIERA

Figura 4.24 Diagrama de clases de la aplicacin.

En el apartado de implementacin se vern con ms detalle los mtodos y


atributos de las clases implementadas.

4.3.2.1.2.Diagramadesecuencia

A continuacin se muestran los diagramas de secuencia de los principales


escenarios de uso del interfaz.

- 109 -
CAPITULO 4 PROCESO DE INGENIERA

Realizar bsqueda

Figura 4.25 Diagrama de Secuencia del escenario Realizar Bsqueda

Precondiciones:

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

El Usuario debe de haber indicado las caractersticas del producto a


buscar.

El Usuario debe de haber pulsado el botn buscar.

Poscondiciones:

Si la consulta devuelve resultados, se formatearn 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 INGENIERA

Obtener detalles de un producto

Figura 4.26 Diagrama de Secuencia del escenario Obtener detalles

Precondiciones:

El Usuario debe haber realizado la bsqueda.

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

Poscondiciones:

El sistema extrae informacin sobre el producto elegido y se la muestra


al usuario.

- 111 -
CAPITULO 4 PROCESO DE INGENIERA

4.3.2.2.DiseodelaInterfazdeUsuario

El interfaz de usuario se puede disear de muchas maneras. Debemos pensar en


la comodidad del usuario, y en ofrecerle un interfaz de fcil uso minimizando al
mximo los tiempos necesarios para el aprendizaje.

Antes de comenzar, se consult la lista de los buscadores web semnticos que ya


estn operativos actualmente (http://www.javi.it/semantic.html). Entre los que hay, se
destacan algunos que han aportado algunas ideas para el diseo de nuestra interfaz
grfica:

Quintura (www.quintura.com) es uno de los ms perfeccionados.


Muestra como una nube de palabras relacionadas que con solo pasar el
ratn sobre ellas te pueden ayudar a afinar los resultados.

Ujiko (www.ujiko.com), este tiene una bonita apariencia y por su modo


de bsqueda, a medida que vas buscando te ofrece diferentes opciones
para encaminar la bsqueda 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 diseo de la interfaz:

Mostrar los diferentes tipos de muebles para que el usuario pueda elegir
el que quiera. Se ha pensado en extraer la jerarqua de clasificacin de
los muebles de la ontologa y volcarla al interfaz en una estructura de
rbol por ejemplo.

Encaminar la bsqueda segn el tipo de mueble elegido, ofreciendo una


serie de caractersticas que el usuario pueda ir especificando con los
valores que desea. Una manera simple e intuitiva de realizarlo sera
mediante desplegables.

Teniendo en cuenta las ideas anteriores y las especificaciones de la aplicacin


Web estudiadas en la Fase de Anlisis se realiza el diseo distinguiendo 3 partes en la
interfaz por la ubicacin que tendrn 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 raz (que es Producto) y el primer nivel del rbol (que
contiene los conceptos Mueble y Composicin). 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 botn de bsqueda. La primera vez que se acceda a la

- 112 -
CAPITULO 4 PROCESO DE INGENIERA

aplicacin esta parte contendr un panel con las propiedades genricas que
puede tener cualquier producto, luego cuando el usuario elige un tipo de
mueble o una composicin se mostrar el panel correspondiente al tipo
seleccionado.

3) La tercera parte es la zona inferior donde se muestran los resultados de la


bsqueda. 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 informacin detallada
sobre un producto especfico de la lista de resultados.

Figura 4.27 Interfaz de usuario

- 113 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

- 114 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

5. IMPLEMENTACINYPRUEBAS

5.1 FASEDEIMPLEMENTACIN

Tras analizar y establecer el diseo de la programacin de la aplicacin, se


dispuso a codificarla. Para ello se tomaron una serie de decisiones de implementacin
teniendo en cuenta los requisitos establecidos en el apartado de anlisis:

La primera decisin a tomar es la plataforma de desarrollo que se va a utilizar. El


grupo de trabajo del departamento Tecnologas de la Informacin donde se ha
desarrollado el proyecto hace uso actualmente de un entorno Java para la
programacin, sobre todo en el desarrollo de las herramientas de catalogacin
basadas en el estndar funStep. De modo que fue Java la plataforma de
desarrollo utilizada, por este motivo y por otros ms motivos dignos de ser
analizados:

1) Java es orientado para la web, su estructura comparte la esencia de la


estructura de la Web Semntica.

2) Nos ofrece multiplataforma. El cdigo generado es de alta calidad, muy


reutilizable y muy extensible.

3) Las herramientas que se han convertido en estndares de facto para


trabajos con web semntica como Jena o Sesame, se basan ambas en la
tecnologa Java.

La siguiente decisin a tomar es qu arquitectura utilizar para el desarrollo de la


aplicacin. Teniendo en cuenta que ha de ser accesible va web, se han barajado
dos opciones:

1) La arquitectura J2EE basada en el patrn Modelo Vista Controlador


(MVC), donde la vista es la pgina HTML y el cdigo que provee de
datos dinmicos a la pgina; el modelo es la lgica de negocio, y el
controlador es el responsable de recibir los eventos de entrada desde la
vista. Esta opcin es interesante para el desarrollo de aplicaciones web
con sofisticados interfaces, ya que trata de realizar un diseo 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 lgica de negocio o de datos. Debido a que el desarrollo de
una aplicacin J2EE tiene un coste de desarrollo considerable y a que la
aplicacin que se pretende disear no ser demasiado compleja, no se ha
optado por esta opcin.

2) Mediante un Applet en java. Un applet es un componente de una


aplicacin 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 IMPLEMENTACIN Y PRUEBAS

Windows, Mozila Firefox, etc.). Es menos costoso disear el interfaz de


esta manera, y el resultado obtenido cumplir con los requisitos
establecidos, por lo cual, se utiliz Java applet para desarrollar la
aplicacin.

El entorno de trabajo escogido para trabajar con semntica 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 ontologas escritas en OWL, DAML y RDFS, un
subsistema de razonamiento, el lenguaje de bsquedas 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 informacin).

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 librera de Java para aplicaciones que
necesitan trabajar internamente con RDF. Sin embargo, todava no es compatible
con OWL, y por ello se eligi Jena 2.

Se utiliz un plugin de Protg, Protg2Jena (Prot2Jena, 2006) para exportar la


ontologa a almacenamiento persistente, utilizando el sistema gestor de bases de
datos MySQL. Y mediante Jena se proceder a cargar un modelo de la ontologa
desde almacenamiento persistente, al que posteriormente podremos atacar tanto
para leer, modificar, crear o realizar bsquedas.

Las bsquedas se llevarn 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 rpido y permite obtener resultados de las bsquedas 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 aade funciones que RDQL no tiene: permite ordenar los


resultados, comprobar ms expresiones (tiempo y fechas, por ejemplo),
usar grafos con nombres, etc.

La sintaxis de SPARQL es muy sencilla.

- 116 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

5.1.1. ImplantacindelaOntologaenlaAplicacin

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
ontologa que nos permita manejar la ontologa y acceder a ella para resolver las
peticiones del usuario.

Un modelo de ontologa es una extensin del modelo RDF de Jena que provee
capacidades adicionales para manejar ontologas. Los modelos de ontologa se crean a
travs de la clase ModelFactory de Jena. Una forma simple de crear un modelo de
ontologa es la siguiente:

OntModelm=ModelFactory.createOntologyModel();

Esto crea un modelo de ontologa 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 jerarquas
sub_class y sub_property.

Para manejar nuestra ontologa se crea el modelo con una configuracin


especfica, a travs 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 ontologa y para realizar las consultas formuladas a partir de las
peticiones del usuario.

Se han implementado dos mtodos que cargan la ontologa a partir del modelo
creado de formas distintas:

1) El mtodo loadOntologyFromOWL() que se corresponde con la carga de


la ontologa desde fichero OWL. Veamos lo que hace este mtodo:

publicvoidloadOntologyFromOwl(){

java.io.InputStreamin=FileManager.get().open(OWL_FILE);

if(in==null){
throw new IllegalArgumentException("Archivo no
encontrado"); }

- 117 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

modelOnt=ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_M
EM_RULE_INF);

//leerelarchivoOWL
modelOnt.read(in,"");
}

Como se puede ver en el trozo de cdigo anterior lo que se realiza es lo


siguiente:

a) Abrir el fichero OWL que contiene la definicin de la ontologa y las


instancias.

b) Crear un modelo de la ontologa como se ha explicado anteriormente.

c) Leer el fichero de la ontologa desde el modelo creado.

2) El mtodo loadOntologyFromDB(), que carga la ontologa desde


almacenamiento persistente. Para esto, previamente se exporta la ontologa a
almacenamiento Jena persistente desde Protg utilizando el plugin
Protg2Jena como ya se ha comentado. El cdigo para implementarlo sera:

publicvoidloadOntologyFromDB(){

IDBConnection conModel = new DBConnection(URL_DB, USER_DB,
PWD_DB,"MySQL");
ModelMakermaker=ModelFactory.createModelRDBMaker(conModel);
ModelRDBmodel=(ModelRDB)maker.openModel(MODEL_NAME);

try{
modelOnt=ModelFactory.createOntologyModel(OntModelSpec.OWL
_DL_MEM_RULE_INF,model);

}catch(Exceptione){
e.printStackTrace();
}
}

a) Se crea la conexin 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 IMPLEMENTACIN Y PRUEBAS

5.1.2. Notasdeimplementacin

Una vez cargada la ontologa en la aplicacin, sta podr acceder a ella para leer,
modificar, crear o bien buscar informacin. Se recogern las peticiones del usuario del
interfaz y se convertirn en consultas SPARQL que se ejecutarn sobre el modelo de
ontologa devolviendo unos resultados que sern formateados y finalmente, mostrados
al usuario.

En este apartado se va a describir un poco cmo se han implementado los


mtodos ms relevantes de cada una de las clases implementadas para llevar a cabo
todas las funcionalidades del sistema.

Clase AppletUI:

El mtodo init() es donde se definen todos los componentes de la


interfaz grfica utilizando la librera swing de java. Nuestro interfaz de
usuario contiene bsicamente los siguientes componentes:

Un JTree que permite navegar por la jerarqua de muebles y


seleccionar un tipo especfico.

Dos paneles principales:

JPPieceOfFurn para la bsqueda de muebles individuales, tales


como silla, cama, mesa, etc. Luego, segn si el tipo de mueble
seleccionado sea una mesa, cama, asiento o mueble de
almacenamiento se visualizar un panel con propiedades
especficas del tipo de mueble seleccionado. As por ejemplo, si
el usuario lo que busca es una mesa, seleccionar mesa en el
rbol, y automticamente se cargar el panel especfico de mesa,
que contiene propiedades especficas 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 nmero de
cajones o nmero de puertas.

JPCompProperties para la bsqueda de composiciones


(compuestas de varios muebles). En este panel el usuario podr
elegir valores de propiedades propias de una composicin, como
ambiente (noche, saln, 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 mtodo start() realiza la llamada al mtodo startUI de la clase


HandlerUI, que inicializa los componentes del interfaz y aade
escuchadores de eventos a los componentes.

- 119 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

El resto de mtodos 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 mtodos de la clase LoaderOntology que


cargan el modelo de ontologa, a continuacin al mtodo crearArbol() el
cual invoca mtodos de la clase ClientOntology que recorren de manera
recursiva la jerarqua de clases de la ontologa y crean una estructura de
rbol en java. Y finalmente, llama al mtodo 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 mtodos
obtainInstancesOfClass() y obtainSubclassesOfClass() de la clase
ClientOntology, que acceden a la ontologa y rellenan los comboboxes.

El mtodo crearArbol() como se ha comentado antes, crea un rbol en


java con los conceptos de la ontologa. Para ello, llama al mtodo
convertirOntologiaEnArbol() de la clase ClientOntology pasndole el
nombre de la clase raz a partir de la cual se quiere construir el JTree.

actionTree() implementa el cdigo que debe ejecutarse cuando el


usuario selecciona un nodo del rbol de muebles. Bsicamente, 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 bsqueda
especificando las caractersticas del mueble que busca.

actionSearch() implementa el cdigo que se ejecuta cuando el usuario


pulsa el botn search. En la Fase de Diseo se vio el diagrama de
secuencia del escenario Realizar bsqueda de un mueble, que
representa las interacciones entre los objetos que tienen lugar a lo largo
del tiempo cuando se ejecuta esta accin.

Cuando lo que busca el usuario es una composicin (caso de uso Buscar


composicin) 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 recogera los parmetros de bsqueda de los componentes del
panel JPCompProperties en vez de JPPieceOfFurn, y en lugar de llamar
al mtodo findPieceOfFurn(ArrayList<String>) de la clase
QueryOntology, llamara a la funcin 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
bsqueda del usuario. En la tabla solo se mostrar informacin bsica
sobre los muebles, como material y precio. Si el usuario desea obtener
ms detalles sobre algn mueble en particular deber seleccionar dicho
producto de la tabla de resultados.

- 120 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Las funciones findPieceOfFurn() y findComp() construyen la consulta


SPARQL a partir de los parmetros recogidos del interfaz, y la ejecutan.
Se construye la cadena con toda la consulta SPARQL, se pasa la cadena a
la funcin create(queryString) de la clase QueryFactory de Jena. Luego
se llama a la funcin create de QueryExecutionFactory pasndole la
query y el modelo de ontologa, y finalmente se ejecuta la consulta y se
obtienen los resultados con la llamada:

ResultSetresults=qe.execSelect();

actionTable() implementa el cdigo 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 ms informacin sobre un
determinado mueble o composicin.

El handler obtiene la fila seleccionada por el usuario y consigue una


referencia a la instancia de mueble correspondiente. Luego llama al
mtodo queryIndividual(String) de la clase QueryOntology, que accede a
la ontologa y obtiene los valores de una serie de propiedades sobre el
mueble a travs 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 IMPLEMENTACIN Y PRUEBAS

5.2 PRUEBASYEVALUACIN

5.2.1. Fundamentosdelaprueba

Cuando se desarrolla un sistema software existen enormes posibilidades de que


se produzcan fallos humanos en las actividades de produccin. Pueden darse errores en
cualquier fase del proceso, desde una mala especificacin de los objetivos, hasta errores
en las fases de diseo y desarrollo.

Es imposible que el ser humano trabaje de una manera perfecta, y por ello, el
desarrollo debe ir acompaado de una actividad que garantice la calidad. As pues, la
prueba del software representa la revisin final de las especificaciones, del diseo y de
la codificacin.

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 funcin 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
aplicacin con interfaz grfica, se deben realizar pruebas funcionales que verifiquen que
el sistema software ofrece a los actores humanos la funcionalidad recogida en su
especificacin.

5.2.2. Pruebasdelsistema

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 tcnicas ms empleadas para la especificacin funcional de sistemas


software son los casos de uso.

Caso de uso Especificar tipo de producto

Fundamentos: El usuario accede a la aplicacin y desea buscar un tipo


especfico 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 IMPLEMENTACIN 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.

Conclusin: 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 IMPLEMENTACIN Y PRUEBAS

Figura 5.2 Prueba El usuario elige buscar Camas Dobles.

Caso de uso Realizar Bsqueda

Como se puede ver en el diagrama de casos de uso del captulo anterior,


este caso de uso es muy genrico e incluye la bsqueda de todos los productos
disponibles (muebles individuales o composiciones), por varias caractersticas.
Se van a mostrar algunos ejemplos de diferentes bsquedas.

Fundamentos: El usuario selecciona los valores que desea de las


propiedades del mueble elegido previamente a travs de los desplegables
y pulsa el botn de buscar.

Caso de prueba 1: El usuario busca muebles de un fabricante


especfico, destinados para dormitorios, de estilo moderno, en
Valencia. Ver figura 5.3.

Caso de prueba 2: El usuario busca conjuntos de saln 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 IMPLEMENTACIN 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 saln cuadradas de


estilo moderno. Ver figura 5.9.

Resultado: El sistema muestra el panel de salida con la lista de muebles


resultado de cada bsqueda.

Conclusin: Prueba superada con xito. El sistema devuelve una tabla


con los resultados de la bsqueda de forma inmediata. En las figuras 5.3,
5.4, 5.5, 5.6 y 5.7 se pueden ver distintos ejemplos de bquedas
realizadas.

- 125 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.3 Ejemplo de bsqueda de muebles de un Fabricante

- 126 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.4 Ejemplo de bsqueda de Conjuntos de saln

- 127 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.5 Ejemplo de bsqueda de Composiciones con camas

- 128 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.6 Ejemplo de bsqueda de camas individuales con cabecero

- 129 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.7 Ejemplo de bsqueda de Sillas modenas en Valencia ciudad

- 130 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.8 Ejemplo de bsqueda de Sillas con un rango de precio

- 131 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.9 Ejemplo de bsqueda de Mesas de saln cuadradas

Caso de uso Obtener detalles de un producto

Fundamentos: El usuario pulsa sobre un resultado de la lista del panel


de resultados solicitando informacin detallada sobre un producto.

Resultado: El sistema muestra el panel de detalles con la informacin


detallada sobre el producto seleccionado.

Conclusin: 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 informacin
sobre los productos seleccionados en las figuras 5.4, 5.5, 5.6, 5.7, 5.8 y
5.9 respectivamente.

- 132 -
CAPITULO 5 IMPLEMENTACIN 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 IMPLEMENTACIN Y PRUEBAS

Figura 5.12 Obtener detalles del producto Carlotta Chair

Figura 5.13 Obtener detalles del producto Dubai Chair

- 134 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

Figura 5.14 Obtener detalles del producto Javea Table 031

- 135 -
CAPITULO 5 IMPLEMENTACIN Y PRUEBAS

5.2.3. PruebasdeConsistenciaenlaOntologa
A parte de las pruebas funcionales del sistema desarrollado, se han realizado
pruebas de consistencias en la Ontologa 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 definicin 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 IMPLEMENTACIN Y PRUEBAS

de una propiedad de tipo Datatype (tipo de dato), solo se pueden usar restricciones
hasValue para propiedades de tipo Object.

Finalmente, despus de solucionar las inconsistencias que se haban detectado se


obtuvo la versin final de la ontologa sin inconsistencias como se puede ver en la
figura 5.16.

Figura 5.16 Chequeo de consistencia de la ontologa con RacerPro

- 137 -
CAPITULO 6 CONCLUSIONES Y TRABAJO FUTURO

- 138 -
CAPITULO 6 CONCLUSIONES Y TRABAJO FUTURO

6. CONCLUSIONESYTRABAJOFUTURO

6.1. Conclusiones
En este apartado se abordan las conclusiones extradas 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 ontologa que defina formalmente y relacione los
conceptos del dominio de muebles y afines, y que est basada en el estndar
internacional funStep (ISO 10303-236). Antes de comenzar el desarrollo de la ontologa
se realiz un anlisis del modelo de datos de ISO funStep para extraer aquellos
conceptos del mbito de la ontologa del mueble y afines y realizar su transcripcin
semntica, como se puede comprobar en el captulo de Proceso de Ingeniera 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 semntica, generando
con ello un marco de fcil actualizacin y extensibilidad. Durante el periodo de
desarrollo de la ontologa, sta ha sido revisada peridicamente por expertos en el
sector (tcnicos de AIDIMA y trabajadores especializados de empresas); y tras su
finalizacin se envi una primera versin a las empresas colaboradoras en funStep
(Grupo de Inters funStep), que la consideraron satisfactoria y til para el sector. La
ontologa 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 informacin entre
fabricantes, distribuidores, comercios y clientes, y ralentiza el lanzamiento de nuevos
productos al mercado. Para solucionarlo, bastara que las empresas del sector usaran el
vocabulario creado de manera comn y unificada. Debido al peso y a la influencia de
AIDIMA entre estas empresas, es segura la utilizacin de la ontologa por muchas de
ellas. La ontologa conseguida es lo bastante completa y detallada como para responder
a las necesidades del sector; en todo caso, los distintos miembros del Grupo de Inters
funStep la ampliarn y mejorarn en el futuro.

Actualmente se est comenzando a integrar la ontologa en otro proyecto


desarrollado por AIDIMA: la herramienta de definicin e intercambio de informacin
de catlogos (Cadef). Con Cadef se pretende enlazar los productos de un catlogo
electrnico a los conceptos definidos en la ontologa, 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 localizacin; por otra parte,
esto constituye el primer paso para aprovechar los productos de los catlogos generados
por Cadef importndolos como instancias de las clases de la ontologa, lo cual ampliara
la base de conocimientos desarrollada en este proyecto y evitara el esfuerzo de tener
que introducir a mano las instancias. El siguiente paso estribara en desarrollar una
herramienta que traduzca la informacin de los catlogos 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 aplicacin web de bsqueda de informacin dirigida al sector
mobiliario basada en la ontologa desarrollada; prototipo que permite realizar consultas
de gran inters para los usuarios, segn se establecieron con expertos del sector.

Al tratarse de un prototipo, la cantidad de informacin que se maneja es


relativamente pequea en comparacin 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 ontologa desde un fichero OWL. Para que el prototipo de buscador
pueda utilizarse con un buen rendimiento en el futuro, cuando se incorporen ms
productos, se ha implementado tambin 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 aplicacin en el futuro, habra que incluir una base
de datos para almacenar la informacin.

A la hora de decidir la manera de implementar la interfaz, se propusieron dos


opciones: desarrollarla mediante un applet o mediante una aplicacin J2EE. Cabe
mencionar que, en esta parte, lo importante para la empresa era aplicar las tecnologas
semnticas para implementar las bsquedas que los usuarios desean realizar y conseguir
una interfaz sencilla que permitiera interactuar de forma cmoda y sencilla con el
sistema y probarlo. La idea es utilizarlo, de momento, como herramienta para presentar
las posibilidades de la ontologa a las empresas del sector; y con ello, fomentar su uso
comn para catalogacin electrnica, integracin automtica de catlogos electrnicos
de distintos fabricantes, anotacin semntica de recursos relacionados con muebles e
introduccin de muebles y complementos en marketplaces. Es decir, el objetivo no era
conseguir una interfaz atractiva ni avanzada. Por ello, despus de haber desarrollado la
ontologa, se decidi realizarlo mediante un applet en Java.

A pesar de usar un applet, se ha mantenido una separacin entre la vista y la


lgica de negocio con el objetivo de mejorar la reusabilidad, de modo que en el futuro
se pueda modificar el interfaz de la aplicacin y reutilizar los paquetes que contienen
toda la lgica de acceso a la informacin y de las consultas.

La aplicacin final desarrollada ha resultado plenamente satisfactoria para el jefe


de proyecto, D. Miguel ngel Abin, al igual que para la directora Da. Mara Jos
Nuez. Se realiz una demostracin final en AIDIMA, a la que asistieron
representantes de varias empresas del sector, que despus de probar la aplicacin
mostraron su inters en adoptar la ontologa para describir y clasificar los productos de
sus catlogos. Como se explica en el apartado 6.2, se prev trabajar en el parseo de los
catlogos desde XML a OWL para poder realizar la carga automtica de los datos y
poder llevar el prototipo a aplicacin industrial.

- 140 -
CAPITULO 6 CONCLUSIONES Y TRABAJO FUTURO

6.2. TrabajoFuturo

Este proyecto ha incorporado por primera vez las tecnologas semnticas 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 bsqueda de informacin, consiguiendo bsquedas ms eficaces y mejor
adaptadas a las necesidades de los usuarios.

La ontologa creada podr extenderse con nuevos conceptos y relaciones, segn


los requerimientos de las empresas colaboradoras. Est prevista ya su utilizacin
combinndola con las herramientas de anotacin semntica desarrollados en el proyecto
europeo ATHENA (Advanced Technologies for Interoperability of Heterogeneous
Enterprise Networks and their Applications), para anotar semnticamente imgenes,
dibujos o diseos de muebles, procedentes de catlogos de fabricantes, distribuidores o
de recursos de la web.

En cuanto a la aplicacin web, se puede pasar de un prototipo a una aplicacin


industrial. Para ello, ya se est trabajando en lo siguiente:

1. Mediante la herramienta Cadef, enlazar los productos de los


catlogos con los conceptos de la ontologa. Hasta el momento se
ha programado una versin beta del Cadef que enlaza con la
ontologa y extrae las propiedades correspondientes a cada
producto. En la figura 6.1. se puede ver una captura de pantalla de
la nueva implantacin de Cadef.

2. Desarrollar una herramienta que analice los catlogos en XML,


generados por Cadef, y transformarlos a ficheros OWL, para poder
importarlos a la ontologa. As se lograr ampliar la base de
conocimientos a la cual accede la aplicacin para resolver las
consultas de los usuarios.

Por ltimo, se prev pasar la aplicacin a una arquitectura J2EE basada en el


patrn MVC (Modelo Vista Controlador) y obtener una interfaz ms avanzada
convirtiendo el cdigo a JSP o adaptndolo a las nuevas tecnologas usando frameworks
de desarrollo como JSF.

- 141 -
CAPITULO 6 CONCLUSIONES Y TRABAJO FUTURO

Figura 6.1 Nueva implantacin del Cadef (Versin beta).

- 142 -
BIBLIOGRAFA

BIBLIOGRAFA

Abin Miguel ngel (2005), El futuro de la Web. XML, RDF/RDFS, ontologas, y la


Web semntica.La ltima versin 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 anotacin lingstico-ontolgica de documentos
de la Web Semntica: 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 Semntica, 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 Tcnica 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.

Gmez-Prez Asuncin, Fernndez-Lpez Mariano y Corcho Oscar (2002), OntoWeb:


Ontology-based Information Exchange for Knowledge Management and Electronic
Commerce .Technical Roadmap.Universidad Politcnica 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, Batrix


Barafort, Pierre Brimont,Mara Jos Nez, Miguel ngel Abin, Herv Panetto, Kurt

- 143 -
BIBLIOGRAFA

Geihs y Richard Stevens (2004), The Methodology to implement services and develop
take up actions towards SMEs, 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 Protg-OWL
plugin and CO-ODE tools Edition 1.0, The University of Manchester, Stanford
University.

Moreno Ortiz, Antonio (2000), Diseo e implementacin de un lexicn computacional


para lexicografa y traduccin automtica.ISSN: 1139-8736. Disponible en
http://elies.rediris.es/elies9/4-1.htm.

Natalia F. Noy y Deborah L. McGuinness (Septiembre 2005), Desarrollo de ontologas-


101:Gua Para Crear Tu Primera Ontologa, 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.

Protg2Jena, 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), Ontologas para servicios web semnticos de
informacin de trfico: descripcin y herramientas de explotacin, tesis doctoral,
Departamento de Informtica, Universitat de Valncia.

Snchez Fernndez Luis y Fernndez Garca Norberto (2005), Universidad de Carlos III
de Madrid, La Web semntica: fundamentos y breve estado del arte, Novtica:
Revista de la Asociacin de Tcnicos de Informtica, 178, 6-12.
T. Berners-Lee, J. Hendler, O Lassila, (2001). The Semantic Web. Scientific American,
May 2001.

Sowa John F.(2000), Knowledge Representation. Logical, Philosofical and


Computational Foundations. Ed Brooks Cole Publishing Co. 132-168. USA.

Vallespir Bruno, Bourrieres Jean-Paul, Ducq Yves (2004), INTEROP NoE Project
Presentaction. University Bordeaux.

Xavier Polanco (2007), Universit Pierre et Marie Curie de Francia, Un modo de


anlisis de la infraestructura cientfica de las tecnologas de la informacin y de las
comunicaciones, Revista CTS 9 (3).

- 144 -
ANEXO I

ANEXOS
Anexo I: FurnitureOntology.owl

En este Anexo se muestran trozos de cdigo OWL de la ontologa generado con


Protg. El ltimo trozo se corresponde con la definicin 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 Abin 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"
>Catlogo 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"
>comercial@passe-avant.com</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 da rene a un equipo de profesionales
altamente cualificados, a partir de una premisa muy clara: diseo 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. Pas 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

>comercial@passe-avant.com</hasElectronic_mail_address>
<hasStreet rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Avda. Aragn</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. Espaa</hasStreet>
<hasElectronic_mail_address rdf:datatype=
"http://www.w3.org/2001/XMLSchema#string"
>divano@divanopiel.com
&lt;divano@divanopiel.com&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"
>Castelln</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:iso10303-
28:express/AP236_Implementation_Subset_LF_arm" xmlns:exp="urn:oid:1.0.10303.28.2.1.1"
xsi:schemaLocation="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm
CC1_subset_Corrected_v2.xsd" express="AP236_Implementation_Subset_LF_arm"
configuration="conf" xsi:type="cadainlofo:uos">

<!-- 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>furnibest@mail.com</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:iso10303-
28:express/AP236_Implementation_Subset_LF_arm" xmlns:exp="urn:oid:1.0.10303.28.2.1.1"
xsi:schemaLocation="urn:iso10303-28:express/AP236_Implementation_Subset_LF_arm
CC1_subset_Corrected_v2.xsd" express="AP236_Implementation_Subset_LF_arm"
configuration="conf" xsi:type="cadainlofo:uos">

<!-- 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 -