Mouna PDF

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-
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-
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-
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-
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-
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-
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-
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 -
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 -
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 -
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 -
Figura 2.3 Captura del Cadef enlazando productos a la ontologa
- 14 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figura 3.1Descomposicin del proyecto en tareas

- 54 -
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 -
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 -
Figura 3.2 Diagrama de Gantt
- 57 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figura 4.5 Diagrama de Product_class y sus relaciones
- 73 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figura 4.10 Diferentes niveles de la taxonoma de muebles
- 85 -
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 -
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 -
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 -
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:first>
<rdf:restrdf:parseType="Resource">
<rdf:first
>$</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 -
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 -
(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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figura 4.18 Caso de uso Buscar Muebles detallado.
Figura 4.19Caso de uso Buscar Composiciones detallado.
- 99 -
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 -
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.
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 -
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 -
Figura 4.21 Diagrama de Actividad Realizar Bsqueda
- 103 -
Figura 4.22 Diagrama de Actividad Obtener detalles
- 104 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figura 5.3 Ejemplo de bsqueda de muebles de un Fabricante
- 126 -
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
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 -
Figura 5.10 Obtener detalles del producto Bedroom Syros 2
Figura 5.11 Obtener detalles del producto Diez4 Single Bed
- 133 -
Figura 5.12 Obtener detalles del producto Carlotta Chair
Figura 5.13 Obtener detalles del producto Dubai Chair
- 134 -
Figura 5.14 Obtener detalles del producto Javea Table 031
- 135 -
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 -
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 -
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 -
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 -
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 -
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"?>

<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>
>(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: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: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:Class>
</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>
>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">
>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:onProperty>
<owl:ObjectProperty rdf:about="#hasUse"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
</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:Class>
<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: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:Class>
<owl:disjointWith>
<owl:Class rdf:about="#WaterBed"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#AirBed"/>
</owl:disjointWith>
>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>
>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">
>(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:Class>
<owl:Class rdf:about="#DomesticChair"/>
<owl:Restriction>
<owl:onProperty>
</owl:onProperty>
<owl:hasValue>
<OtherHomeUse rdf:ID="StudyOrOfficeHomeUse">
<rdfs:label xml:lang="en">Studies</rdfs:label>
>Study or office use</hasName>
</OtherHomeUse>
</owl:hasValue>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty>
</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:Restriction>
</owl:Class>
</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>
>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">
>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">
>(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:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="VisitorChair"/>
</owl:disjointWith>
<rdfs:label xml:lang="en">Work Chair</rdfs:label>
<owl:Class>
<owl:Restriction>
<owl:onProperty>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:about="#Swivel"/>
</owl:Restriction>
<owl:Restriction>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
</owl:onProperty>
</owl:Restriction>
<owl:Class rdf:ID="OfficeChair"/>
</owl:Class>
</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>
>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:onProperty>
<owl:DatatypeProperty rdf:about="#hasCastors"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:Class>
<owl:Restriction>
<owl:hasValue>
<ChildrenUse rdf:ID="ChildrenTransportUse">
>Children transport use</hasName>
<rdfs:label xml:lang="en">Childrens Transport use</rdfs:label>
</ChildrenUse>
</owl:hasValue>
<owl:onProperty>
</owl:onProperty>
</owl:Restriction>
<owl:Class rdf:about="#ChildrenPieceOfFurniture"/>
- 154 -
ANEXO I
</owl:Class>
>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">
>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:onProperty>
</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>
>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:Class>
<owl:Restriction>
<owl:hasValue rdf:resource="#RestaurantAndBarUse"/>
<owl:onProperty>
- 156 -
ANEXO I
</owl:onProperty>
</owl:Restriction>
<owl:Class rdf:ID="Stool"/>
</owl:Class>
<rdfs:label xml:lang="en">Bar Stool</rdfs:label>
>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">
>A shower screen.</rdfs:comment>
<owl:Class>
<owl:Class rdf:about="#Screen"/>
<owl:Restriction>
<owl:hasValue>
<OtherHomeUse rdf:ID="BathroomHomeUse">
<rdfs:label xml:lang="en">Bathrooms</rdfs:label>
>Bathroom home use</hasName>
</OtherHomeUse>
</owl:hasValue>
<owl:onProperty>
</owl:onProperty>
</owl:Restriction>
</owl:Class>
<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>
>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>
>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:Class>
<owl:Restriction>
<owl:onProperty>
</owl:onProperty>
<owl:hasValue>
<OtherHomeUse rdf:ID="KitchenHomeUse">
<rdfs:label xml:lang="en">Kitchens</rdfs:label>
>Kittchen use</hasName>
</OtherHomeUse>
</owl:hasValue>
</owl:Restriction>
<owl:Class rdf:about="#DomesticRack"/>
</owl:Class>
</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:Restriction>
</rdfs:subClassOf>
<owl:Class>
<owl:Restriction>
<owl:hasValue rdf:resource="#UrbanFurnitureUse"/>
<owl:onProperty>
</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:Class>
<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>
>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>
>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">
>Base giratoria</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Pedestal"/>
</owl:disjointWith>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#FrameTableBase"/>
<owl:disjointWith>
</owl:disjointWith>
<rdfs:subClassOf>
</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>
<rdfs:subClassOf>
</rdfs:subClassOf>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
</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>
>Electric-powered wheelchair for people with disabilities.</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#SlopChest">
>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>
>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">
>A big table used for conference meetings.</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#OfficeTable"/>
</rdfs:subClassOf>
<owl:disjointWith>
</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">
>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>
>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>
>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>
</rdfs:subClassOf>
</owl:Class>
<Catalogue rdf:ID="CatalogoMariner">
>Catlogo Mariner S.A.</hasName>
<hasDate rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>2008</hasDate>
<hasProvider>
<Manufacturer rdf:ID="Mariner">
>Mariner S.A.</hasName>
<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Mariner S.A.</rdfs:label>
</Manufacturer>
</hasProvider>
>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>
>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"/>
>Mesa Alina (MX 2200)</hasName>
>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>
>Andreu World</rdfs:label>
<hasCatalogue>
<Catalogue rdf:ID="CatalogueAndreuWorld">
<hasProduct>
<Chair rdf:ID="CarlotaChair">
<hasBase>
<HighLeg rdf:ID="HighLeg_CarlotaChair"/>
</hasBase>
- 164 -
ANEXO I
>Carlota Chair</hasName>
>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">
></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>
>55.0</hasLength>
<hasMaterial>
<Wood rdf:ID="BeechWood">
>Beech Wood</hasName>
>Beech Wood</rdfs:label>
>"Madera de Haya", "haya", "madera", "wood"</rdfs:comment>
</Wood>
</hasMaterial>
<hasCastors rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>false</hasCastors>
<hasPossibleColour rdf:resource="#Gray"/>
<hasPossibleColour rdf:resource="#Brown"/>
<hasCommerce rdf:resource="#CosinCosin"/>
>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>
>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">
<hasPostal_code rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>03720</hasPostal_code>
<hasElectronic_mail_address xml:lang="en"
></hasElectronic_mail_address>
>www.martinezmuebles.com</hasUrl>
>Alicante</hasRegion>
>BENISSA</hasTown>
>Avda. Pas Valenci</hasStreet>
</Address>
</hasAddress>
>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">
>Valencia</hasRegion>
<hasTelephone_number rdf:datatype=
>963 61 37 62</hasTelephone_number>
>96 362 00 34</hasTelex_number>
>Valencia</hasTown>
>32-34</hasStreet_number>
<hasCountry rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Spain</hasCountry>
- 166 -
ANEXO I
>comercial@passe-avant.com</hasElectronic_mail_address>
>Avda. Aragn</hasStreet>
</Address>
</hasAddress>
</Shop>
</hasCommerce>
<hasBase>
<CantileverFrame rdf:ID="CantileverFrame_LiealChair">
<hasMaterial rdf:resource="#Iron"/>
<hasPossibleFinishing>
<OtherFinish rdf:ID="Chrome">
>Chrome</rdfs:label>
>"Cromado"</rdfs:comment>
</OtherFinish>
</hasPossibleFinishing>
</CantileverFrame>
</hasBase>
<hasPossibleFinishing rdf:resource="#Chrome"/>
<hasSeat>
<SeatPart rdf:ID="SeatPart_LinealChair">
<hasPossibleColour rdf:resource="#White"/>
<hasPossibleFinishing rdf:resource="#Lacquered"/>
</SeatPart>
</hasSeat>
>52.5</hasLength>
<hasCommerce rdf:resource="#Sindora"/>
<hasBackrest>
<Backrest rdf:ID="Backrest_LinealChair">
<hasPossibleFinishing rdf:resource="#Lacquered"/>
</Backrest>
</hasBackrest>
>51.5</hasWidth>
<hasCommerce rdf:resource="#MueblesGozalbo"/>
<hasPrice>
<Price rdf:ID="Price_LinealChair">
></hasUnit>
>MiddlePrice</hasDescriptionPrice>
</Price>
</hasPrice>
>Chair Lineal</rdfs:label>
<hasMaterial rdf:resource="#Iron"/>
>src/es/pfc/resources/img/SILLAS/LINEAL_CHAIR.jpg</hasImage>
<hasCommerce>
- 167 -
ANEXO I
<Commerce rdf:ID="DivanoPielSegorbe">
<hasAddress>
<Address rdf:ID="Address_Divano">
>96471202</hasTelex_number>
>http://www.divanopiel.com/</hasUrl>
>Avda. Espaa</hasStreet>
>divano@divanopiel.com
<divano@divanopiel.com></hasElectronic_mail_address>
<hasTelephone_number rdf:datatype=
>964712699</hasTelephone_number>
>Castelln</hasRegion>
>SEGORBE</hasTown>
<hasCountry rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Spain</hasCountry>
</Address>
</hasAddress>
>Divano Piel Segorbe</rdfs:label>
<hasProvince rdf:resource="#Castellon"/>
</Commerce>
</hasCommerce>
>Structure of iron rod chrome, trim and back panel of oak</rdfs:comment>
>Lineal Chair (SI 0584)</hasName>
>51.5</hasHeight>
</Chair>
</hasProduct>
<hasProduct>
<Chair rdf:ID="ManilaChair">
<hasSeat>
<SeatPart rdf:ID="SeatPart_ManilaChair">
<hasPossibleFinishing rdf:resource="#Leather"/>
</SeatPart>
</hasSeat>
<hasBase>
<HighLeg rdf:ID="HighLeg_ManilaChair">
<hasMaterial rdf:resource="#BeechWood"/>
<hasPossibleColour rdf:resource="#Black"/>
</HighLeg>
</hasBase>
>src/es/pfc/resources/img/SILLAS/MANILA_CHAIR.jpg</hasImage>
<hasCommerce rdf:resource="#MoblesPass-Avant_AlfafarSedavi"/>
- 168 -
ANEXO I
>Manila Chair</rdfs:label>
>Manila Chair (SO 2017)</hasName>
>80.0</hasHeight>
<hasArmrests>
<Armrest rdf:ID="Armrests_ManilaChair"/>
</hasArmrests>
>Structure of beech wood, trim and back upholstered</rdfs:comment>
<hasNumberOfLegs rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>4</hasNumberOfLegs>
<hasSize>
<Size rdf:ID="MiddleSize">
>Middle</hasName>
>Middle</rdfs:label>
</Size>
</hasSize>
>58.5</hasWidth>
<hasPossibleColour rdf:resource="#Black"/>
<hasPrice>
<Price rdf:ID="Price_ManilaChair">
></hasUnit>
>MiddlePrice</hasDescriptionPrice>
</Price>
</hasPrice>
>54.0</hasLength>
<hasMaterial rdf:resource="#BeechWood"/>
<hasBackrest>
<Backrest rdf:ID="Backrest_ManilaChair">
</Backrest>
</hasBackrest>
</Chair>
</hasProduct>
>Andreu World Catalog</hasName>
>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">

<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

<cadainlofo:Product_class id="pc_0001">
<id>FurniB-C001</id>
<name>Catalog C 001</name>
<level_type>catalog</level_type>
</cadainlofo:Product_class>
<id>Legs</id>
<name>Legs</name>
<level_type>line</level_type>
<id>Boards</id>
<name>Boards</name>
<id>Tables</id>
<name>Tables</name>
<id>Chairs</id>
<name>Chairs</name>
<id>Legs_1</id>
<name>Legs_1</name>
<level_type>product</level_type>
<id>Legs_2</id>
<name>Legs_2</name>
<id>Legs_3</id>
<name>Legs_3</name>
<id>Board_1</id>
<name>Board_1</name>
<id>Board_2</id>
<name>Board_2</name>
- 172 -
ANEXO II
<id>Table_1</id>
<name>Table_1</name>
<id>Table_2</id>
<id>Table_3</id>
<id>Chair_1</id>
<name>Chair_1</name>
<id>Chair_2</id>

<cadainlofo:Product_class_relationship id="pcr_0001">
<relating ref="pc_0001"/>
<related ref="pc_0002"/>
<relation_type>hierarchy</relation_type>
</cadainlofo:Product_class_relationship>
- 173 -
ANEXO II
- 174 -
ANEXO II
<relation_type>composition</relation_type>

<cadainlofo:Specification_category id="sc_0001">
<id>colour</id>
<description>Available catalog colours</description>
<implicit_exclusive_condition>true</implicit_exclusive_condition>
</cadainlofo:Specification_category>
<id>material</id>
<description>Available catalog materials</description>
<id>wheels</id>
<description>determines if the product has wheels</description>
<id>fabrics</id>
<description>Available catalog fabrics for chairs</description>
- 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:Specification id="s_0001">
<id>G</id>
<name>Green</name>
<category ref="sc_0001"/>
<package>false</package>
</cadainlofo:Specification>
<id>B</id>
<name>Blue</name>
<id>Y</id>
<name>Yellow</name>
<id>R</id>
<name>Red</name>
<id>O</id>
<name>Orange</name>
- 176 -
ANEXO II
<id>Wh</id>
<name>White</name>
<id>Bl</id>
<name>Black</name>
<id>I</id>
<name>Iron</name>
<id>Wo</id>
<name>Wood</name>
<id>Pl</id>
<name>Plastic</name>
<id>ww</id>
<name>with wheels</name>
<id>wow</id>
<name>without wheels</name>
<id>B01</id>
<name>Boudeaux_01</name>
- 177 -
ANEXO II
<id>PX</id>
<name>Pistachio_X</name>
<id>OFA</id>
<name>Old_Fashion_Aubergine</name>



<cadainlofo:Product_specification id="ps_0001">
<id>legs_1a</id>
<name>legs_1a</name>
<description>this is a configured leg</description>
<item_context ref="pc_0006"/>
<defining_specifications>

<cadainlofo:Specification ref="s_0001"/>

</defining_specifications>
</cadainlofo:Product_specification>


<id>legs_1c</id>
<name>legs_1c</name>



<id>legs_1c</id>



<id>legs_1d</id>
- 178 -
ANEXO II
<name>legs_1d</name>


<id>legs_2a</id>


<id>legs_2b</id>
<name>legs_2b</name>

<id>legs_2c</id>

<id>legs_2d</id>
- 179 -
ANEXO II


<id>legs_3a</id>

<id>legs_3b</id>
<name>legs_3b</name>


<id>legs_3c</id>


<id>legs_3d</id>

- 180 -
ANEXO II


<id>legs_3e</id>
<name>legs_3e</name>


<id>legs_3f</id>
<name>legs_3f</name>


<id>Board_1a</id>
<name>Board_1a</name>
<description>this is a configured board</description>


<id>Board_1b</id>
<name>Board_1b</name>

- 181 -
ANEXO II
<id>Board_1c</id>
<name>Board_1c</name>


<id>Board_1d</id>
<name>Board_1d</name>


<id>Board_1e</id>
<name>Board_1e</name>


<id>Board_1f</id>
<name>Board_1f</name>


<id>Board_1g</id>
<name>Board_1g</name>
- 182 -
ANEXO II


<id>Board_1h</id>
<name>Board_1h</name>


<id>Board_2a</id>
<name>Board_2a</name>


<id>Board_2b</id>
<name>Board_2b</name>


<id>Board_2c</id>
<name>Board_2c</name>
- 183 -
ANEXO II



<id>Board_2d</id>
<name>Board_2d</name>


<id>Board_2e</id>
<name>Board_2e</name>


<id>Board_2f</id>
<name>Board_2f</name>


<id>Board_2g</id>
<name>Board_2g</name>
- 184 -
ANEXO II


<id>Board_2h</id>
<name>Board_2h</name>


<id>Table_1a</id>
<name>Table_1a</name>

<id>Table_2a</id>

<id>Table_3a</id>
- 185 -
ANEXO II


<id>Chair_1a</id>
<name>Chair_1a</name>






<id>Chair_2a</id>
<name>Chair_2a</name>
<description>this is a possible group configuration</description>




</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">

<id>Chairs</id>
<name>Chairs</name>
<id>Chair_1</id>
<id>Chair_2</id>



<cadainlofo:Applied_independent_property id="aip_0001">
<name>ergonomic</name>
<described_element>
- 187 -
ANEXO III
</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>
<base_independent_property ref="ip_0002"/>
</cadainlofo:Applied_independent_property>
<cadainlofo:Independent_property id="ip_0002">
<id>slogan</id>
<property_type>slogan</property_type>
</cadainlofo:Independent_property>

<cadainlofo:Assigned_property id="ap_0001">
<name>price</name>
<described_element>
</cadainlofo: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:Assigned_property>
<cadainlofo:Property_representation id="pr_0002">
<property ref="ap_0002"/>
<rep ref="r_0002"/>
</cadainlofo:Property_representation>

<cadainlofo:Representation id="r_0001">
<context_of_items ref="rc_0001"/>
<items ref="niwu_0001"/>
</cadainlofo:Representation>
<cadainlofo:Representation_context id="rc_0001">
<id>price in Spain</id>
<kind>price</kind>
</cadainlofo:Representation_context>
- 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 -

Mouna PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Mouna PDF

Cargado por

Copyright:

Formatos disponibles

DESARROLLODEUNAONTOLOGAYDEUN

PROYECTO FIN DE CARRERA

Agradecer en primer lugar a Dios por darme fuerza y voluntad

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

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

A Mara Jos Nez por ofrecerme la idea y darme la

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

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

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

Figura 2.1 Componentes de la interoperabilidad en una empresa ................................ - 8 -

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

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

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

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

La herramienta de bsqueda implementada permitir al usuario final encontrar

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

Desarrollo de una base de conocimiento que almacene informacin sobre el

Desarrollo de una herramienta de bsqueda semntica que usar los conceptos

Los metadatos estructuran solamente los contenidos; las ontologas permiten

Las ontologas favorecen la comunicacin entre personas, organizaciones y

Favorecen tambin la comunicacin entre aplicaciones y la comprensin comn

automtica, sin esfuerzo por parte del usuario.

Generar un modelo de informacin comn para el mueble.

Desarrollar un mtodo comn para el intercambio de informacin

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

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

La construccin de una ontologa que defina los conceptos relacionados con el

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

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

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

Durante aquella entrevista en AIDIMA la directora de TI me explic que

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

1) Definir un vocabulario comn, expresado formalmente, para representar

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

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

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

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

Para entender bien esto, veamos algunas definiciones de interoperabilidad:

La capacidad de dos entidades (tpicamente aplicaciones de software)

La capacidad de interpretar datos de manera uniforme (un comando

La capacidad para compartir e intercambiar datos que usan sintaxis y

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

La capacidad de dos o ms sistemas o componentes para intercambiar

Existen tres niveles de interoperabilidad, mencionados en el prrafo anterior

Interoperabilidad tcnica. Se refiere a la capacidad de dos sistemas

Interoperabilidad sintctica. Se refiere a la capacidad de los SI para leer los

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

La interoperabilidad es muy importante para las empresas porque ayuda a

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

Para conseguir la interoperabilidad se necesita integrar tres componentes

Arquitecturas y plataformas para proporcionar la implementacin de soluciones.

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

Ontologas para identificar semnticas de interoperabilidad en la empresa.

Figura 2.1 Componentes de la interoperabilidad en una empresa

Los problemas derivados de la interoperabilidad provienen de los procesos

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

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

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

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

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

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

Partes de productos que se pueden vender como productos separados:

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