Teleeducación WWW

DEPARTAMENTO DE COMUNICACIONES
ESPECIFICACIN OWL DE UNA

ONTOLOGA PARA TELEEDUCACIN EN
LA WEB SEMNTICA
TESIS DOCTORAL PROPUESTA POR:

ROBERTO ROMERO LLOP
DIRIGIDA POR EL DOCTOR:

CARLOS ENRIQUE PALAU SALVADOR
VALENCIA, 2007
Resumen
Debido al gran desarrollo de la World Wide Web, tanto en cantidad de
contenidos y nodos como en velocidades de acceso, aparecen por parte de la
comunidad cientfico-tcnica propuestas de utilizacin de la misma con
objetivos ms ambiciosos que la mera descarga de ficheros para ser
presentados al usuario.
Con esa finalidad se desarrolla la Web Semntica, sistema que pretende

introducir informacin entendible por Agentes Inteligentes, permitiendo de
este modo que estos Agentes puedan aumentar sus bases de conocimiento y
realizar inferencias que faciliten procesos realizados actualmente de forma
manual por los usuarios. De esta forma surgen los lenguajes ontolgicos
para la web, y en concreto el lenguaje recomendado por la World Wide Web
Consortium (W3C) denominado Web Ontology Language (OWL), as como
razonadores relacionados como FACT++, Racer y Pellet.
A ms, con el objetivo de aprovechar el potencial de la web, se han ido

generando gran cantidad de contenidos educativos, que debido a los altos
costes de produccin generan una necesidad de potenciar la reutilizacin de
dichos contenidos. Aparece en este caso el concepto de objeto educativo,
que es susceptible de ser reaprovechado para otras experiencias de
aprendizaje, con alguna modificacin o sin modificacin alguna, generando
la denominada interoperabilidad de objetos educativos.
El presente trabajo pretende potenciar esta interoperabilidad de objetos

educativos. Para ello se especifica una ontologa completa para
teleeducacin, basada en la lgica descriptiva y desarrollada en el lenguaje
OWL, para que pueda ser utilizada por medio de la Web Semntica. Se
estudian, desarrollan e implementan dentro de esta ontologa conceptos
relacionados con la interaccin de los distintos agentes que intervienen en
una experiencia de aprendizaje a travs de la web.
La ontologa presentada va adems acompaada de una especificacin de

arquitectura de pares o Peer to Peer (P2P) basada en las arquitecturas de
tablas de bsqueda distribuidas (DHTs), que denominaremos DHT
Semntica. La DHT Semntica est diseada para permitir la explotacin
por parte de Agentes Inteligentes de la ontologa especificada, con una alta
tolerancia a fallos en nodos de la arquitectura. Estos Agentes asisten en la
bsqueda de objetos educativos ms all de la bsqueda por palabras claves.
Finalmente, tanto la ontologa como la arquitectura se validan utilizando un
conjunto de experiencias educativas on-line reales.
Resum
Degut al gran desenvolupament de la World Wide Web, tant en quantitat de
continguts i nodes como en velocitats daccs, apareixen per part de la
comunitat cientfic tcnica propostes dutilitzaci de la mateixa amb
objectius ms ambiciosos que la simple descrrega de fitxers per a ser
presentats a lusuari.
Amb esta finalitat es desenvolupa la Web Semntica, sistema que pretn

introduir informaci comprensible per Agents Intelligents, permetent desta
manera que estos Agents puguen augmentar les seues bases de coneixement
i realitzar inferncies que faciliten processos realitzats actualment de forma
manual per els usuaris. Desta manera apareixen els llenguatges ontolgics
per a la web, i en concret el llenguatge recomanat per la World Wide Web
Consortium (W3C) anomenat Web Ontology Language (OWL), aix com
raonadors relacionats com FACT++, Racer i Pellet.
A ms, amb lobjectiu daprofitar el potencial de la web, shan anat generant

gran quantitat de continguts educatius, que degut als alts costos de
producci generen una necessitat de potenciar la reutilitzaci dels
anomenats continguts. Apareix en eixe cas el concepte dobjecte educatiu,
que pot tornar a ser aprofitat per a altres experincies daprenentatge, amb
alguna modificaci o sense modificaci alguna, generant la denominada
interoperabilitat dobjectes educatius.
El present treball pretn potenciar esta interoperabilitat dels objectes

educatius. Per a aconseguir-ho sespecifica una ontologia completa per a
teleeducaci, basada en la lgica descriptiva y desenvolupada en el
llenguatge OWL, per tal que puga ser utilitzada mitjanant la Web
Semntica. Sestudien, desenrotllen i implementen dins desta ontologia
conceptes relacionats amb la interacci dels diferents agents que intervenen
en una experincia daprenentatge mitjanant la web.
Lontologia presentada va tamb acompanyada duna especificaci

darquitectura de parells o Peer to Peer (P2P) basada en les arquitectures de
taules de cerca distribudes (DHTs),que denominarem DHT Semntica. La
DHT Semntica est dissenyada per a permetre lexplotaci per part
dAgents Intelligents de lontologia especificada, amb una alta tolerncia a
errades en nodes de larquitectura. Estos Agents ajuden en la cerca
dobjectes educatius ms enll de la cerca per paraules clau. Finalment, tant
lontologia com larquitectura es validen utilitzant un conjunt dexperincies
educatives on-line reials.
Abstract
Due to the development of the World Wide Web, in the number of contents,
nodes and transmission speeds, the scientific community is making
proposals for different uses. These uses are nowadays far more ambitious
than downloading files to be rendered to the user.
The Semantic Web is developed with this aim. The Semantic Web includes
information which can be understood by Intelligent Agents (IA). In this
process, the IAs can expand their Knowledge Bases (KB) and perform
inferences that can ease some human tasks. The information in the Semantic
Web uses different ontology languages for the web, as the World Wide Web
Consortium (W3C) recommendation named Web Ontology Language
(OWL). The inferences can be done by different Inference Engines (IEs) as
FACT++, Racer and Pellet.
In addition to this, many educative contents have appeared in the web, with
high production cost. For this reason reusing contents is nowadays a need,
with little or no changes. These units of contents to be independently shared
are know as Learning Objects (LOs). These LOs have to interoperate among
them in order to build e-learning experiences.
The document presented fosters this LOs interopeability. To achieve this

objective, a complete ontology is specified, based on Description Logic
(DL) and developed in OWL, in order to be used in the Semantic Web. In
this ontology, concepts related to the different relationships among the
stakeholders of an e-learning experience are studied, developed and
implemented.
A new architecture called Semantic DHT is defined in order to exploit the

ontology. The Semantic DHT is a Peer to Peer (P2P) architecture based on
Distributed HastTables (DHTs), and allows the Intelligent Agents access to
the ontological information, with a high node fail tolerance. These Agents
facilitate the ontological searches done by the users. Finally, the ontology
and the architecture are validated against real e-learning experiences.
Agradecimientos
Isaac Newton escribi Si he visto ms all es gracias a que he subido a
hombros de gigantes. No me gustara empezar este documento sin
agradecer a todos los gigantes que me han ayudado y apoyado a la hora de
poder ir ms all, y que sin ellos este trabajo no hubiera sido posible.
En primer lugar a mi director de tesis D. Carlos Enrique Palau Salvador, por

su dedicacin a este trabajo y por saber indicarme lneas y caminos a seguir
que han sido cruciales para el desarrollo satisfactorio de las investigaciones
y resultados. Tambin agradezco a l y al grupo de investigacin al que
pertenece por haberme introducido en el campo de la teleformacin desde
mis ltimos aos de la carrera.
A D. Patricio Montesinos Sanchis y D. Mnica Lpez Sieben, director y

subdirectora del Centro de Formacin Permanente de la Universidad
Politcnica de Valencia, centro al que pertenezco desde hace diez aos. Les
agradezco el haberme facilitado y apoyado en todo momento en la
realizacin de la tesis doctoral, y por considerar que el desarrollo y la
formacin de las personas es un aspecto clave en un puesto de trabajo.
Agradezco tambin al grupo de sistemas de informacin del centro, y en
especial a Vctor y Rafel, que han realizado crticas constructivas a lo largo
del todo el proceso. Espero poder ayudar a Vctor ahora que le llega su
oportunidad.
Deseo agradecer a gigantes de la comunidad cientfico-tcnica que slo

conozco por su trabajo, como Tim Berners-Lee e Ian Horrocks, que han
servido de inspiracin y gua para esta tesis.
Finalmente a mi familia, por haber estado en todo momento animndome a

continuar este camino y saber disculpar la falta de la merecida atencin a
ellos debido a las parcelas de tiempo ocupadas en la investigacin y
desarrollo de este trabajo. En especial a mi mujer Eliana, que ms ha sufrido
mis noches y fines de semana de dedicacin. Han sido gigantes en la
determinacin de que tena que continuar con este objetivo cuando yo
mismo flaqueaba y han sabido ver siempre la luz al final del tnel.
A Eliana
DEPARTAMENTO DE COMUNICACIONES
ESPECIFICACIN OWL DE UNA

ONTOLOGA PARA TELEEDUCACIN EN
LA WEB SEMNTICA
TESIS DOCTORAL PROPUESTA POR:

ROBERTO ROMERO LLOP
DIRIGIDA POR EL DOCTOR:

CARLOS ENRIQUE PALAU SALVADOR
VALENCIA, 2007
ndice
Captulo 1: Introduccin .......................................................................... 1

1.1 Introduccin ................................................................................... 1
1.2 Motivacin de la Tesis ................................................................... 4
1.3 Objetivos ........................................................................................ 5
1.4 Principales aportaciones................................................................. 7
1.5 Retos encontrados .......................................................................... 8
1.6 Alcance de la Tesis ........................................................................ 9
1.7 Organizacin de la memoria ........................................................ 10
Captulo 2: Estudio del Estado del Arte................................................. 15
2.1 Introduccin ................................................................................. 15
2.2 Estado del arte de la Web actual. Web Semntica....................... 16
2.2.1 Introduccin ......................................................................... 16
2.2.2 Web Sintctica ..................................................................... 18
2.2.3 Web 2.0 ................................................................................ 19
2.2.4 Web Semntica .................................................................... 21
2.2.5 Estructura de capas............................................................... 22
2.2.5.1 Unicode + URI Smbolos e Identificadores de Recursos. 23
2.2.5.2 XML + NS + XML-s. Capa de Intercambio de datos...... 24
2.2.5.3 RDF + RDF+s. Capa de Aserciones. ............................... 26
2.2.5.4 Capa Ontolgica, capa Lgica, capa de Prueba ............... 29
2.2.5.5 Capa de Verdad y Firma Digital ...................................... 29
2.3 Estado del arte en Ontologas para Teleeducacin ...................... 30
2.3.1 Introduccin ......................................................................... 30
2.3.2 Teoras de aprendizaje ......................................................... 31
2.3.2.1 Conductismo (Behavioral) ............................................... 31
2.3.2.2 Cognoscitivismo (Information Processing) ..................... 32
2.3.2.3 Constructivismo ............................................................... 32
2.3.3 Teleeducacin ...................................................................... 33
2.3.3.1 Reutilizacin .................................................................... 34
2.3.4 Iniciativas de Teleeducacin................................................ 35
2.3.4.1 Tipos de iniciativas en Teleeducacin ............................. 35
2.3.4.2 IMS .................................................................................. 37
2.3.4.3 OKI................................................................................... 38
2.3.4.4 IEEE LTSA ...................................................................... 39
2.3.4.5 ADL-SCORM .................................................................. 39
2.3.4.6 SIF.................................................................................... 41
2.3.4.7 OpenUSS.......................................................................... 41
2.3.4.8 SUN Microsystems E-Learning Framework.................... 42
2.3.4.9 Otras Iniciativas ............................................................... 42
ndice
2.3.5 Ontologas en Teleeducacin ............................................... 43

2.3.6 Estado del arte en las interacciones de tipo Foro ................. 47
2.3.6.1 Motivacin de los Foros................................................... 49
2.3.6.2 Limitaciones de los Foros ................................................ 51
2.3.6.3 Caracterizacin de los foros............................................. 52
2.3.6.4 Metadatos y Ontologas en los Foros............................... 54
2.3.7 TrackBack ............................................................................ 56
2.3.7.1 Funcionamiento de Trackback ......................................... 57
2.3.7.2 Metainformacin en Trackback ....................................... 58
Captulo 3: Lgica y Web Semntica..................................................... 61
3.1 Introduccin ................................................................................. 61
3.2 Lgica y razonamiento................................................................. 62
3.2.1 Introduccin ......................................................................... 62
3.2.2 Tipos de lgica ..................................................................... 63
3.2.3 Razonamiento ...................................................................... 65
3.2.4 Lgica Proposicional LP...................................................... 66
3.2.4.1 Sintaxis en LP .................................................................. 66
3.2.4.2 Semntica en LP............................................................... 67
3.2.4.3 Formulacin en LP........................................................... 68
3.2.4.4 Razonamiento en LP ........................................................ 70
3.2.4.5 Razonamiento por enumeracin....................................... 71
3.2.4.6 Razonamiento por mtodo Tableaux ............................... 72
3.2.5 Lgica de Primer Orden (FOL)............................................ 75
3.2.5.1 Sintaxis en FOL ............................................................... 75
3.2.5.2 Semntica en FOL............................................................ 76
3.2.5.3 Formulacin en FOL........................................................ 79
3.2.6 Lgica Descriptiva DL......................................................... 80
3.2.6.1 Introduccin ..................................................................... 80
3.2.6.2 Sintaxis y Semntica en DL ............................................. 83
3.2.6.3 Tipos de DL ..................................................................... 85
3.2.6.4 Razonamiento en DL ....................................................... 87
3.2.6.5 Suposicin de mundo abierto (OWA).............................. 88
3.2.6.6 Suposicin de nombres nicos (UNA) ............................ 89
3.3 Lenguajes ontolgicos.................................................................. 90
3.3.1 Introduccin ......................................................................... 90
3.3.2 Tipologa de lenguajes ontolgicos...................................... 92
3.3.3 KIF/SKIF ............................................................................. 95
3.3.4 RuleML ................................................................................ 97
3.3.5 OWL..................................................................................... 98
3.3.5.1 Introduccin e Historia..................................................... 98
3.3.5.2 Tipos de OWL.................................................................. 99
ndice
3.3.5.3 Constructores y axiomas en OWL ................................ 100

3.3.5.4 Ejemplo de uso: OWL-S ................................................ 104
3.3.6 SWRL ................................................................................ 107
Captulo 4: Primeras interacciones: Evaluaciones ............................. 109
4.1 Introduccin ............................................................................... 109
4.2 Motivacin de las evaluaciones ................................................. 111
4.3 Limitaciones de la Evaluaciones................................................ 113
4.4 Metadatos y Ontologas en las evaluaciones.............................. 115
4.4.1 IMS QTI............................................................................. 116
4.4.1.1 Elementos principales de IMS QTI................................ 117
4.4.1.2 Interacciones en IMS QTI.............................................. 118
4.4.1.3 Empaquetado en IMS QTI ............................................. 121
4.4.1.4 Metadatos en IMS QTI .................................................. 121
4.4.2 TeML: Ontologa basada en XML para evaluaciones ....... 128
4.4.2.1 Elementos principales de la ontologa ........................... 129
4.4.2.2 Clasificacin pedaggica ............................................... 131
4.4.2.3 Realimentacin del sistema: Clculo de la dificultad .... 132
4.4.2.4 Implementacin del modelo........................................... 136
4.4.2.5 Metadatos de la Aplicacin: TeML ............................... 138
4.4.2.6 Metadatos de los exmenes............................................ 139
4.4.2.7 Metadatos de las contestaciones a los exmenes ........... 140
4.4.2.8 Metadatos de las preguntas ............................................ 140
4.5 Conclusiones .............................................................................. 142
Captulo 5: Arquitectura ...................................................................... 145
5.1 Introduccin ............................................................................... 145
5.2 Arquitecturas de repositorios de contenidos educativos ............ 146
5.3 Arquitecturas P2P ...................................................................... 152
5.3.1 Desarrollo de las arquitecturas P2P ................................... 154
5.3.2 Ventajas de las arquitecturas P2P ...................................... 156
5.3.3 Inconvenientes de las arquitecturas P2P ............................ 159
5.4 Distributed HashTables (DHT).................................................. 160
5.5 Arquitectura propuesta............................................................... 165
5.5.1 DHT Semntica.................................................................. 166
5.5.2 Descripcin del funcionamiento de la arquitectura............ 170
5.5.2.1 Fase de definicin y creacin de la ontologa a utilizar. 171
5.5.2.2 Fase de formacin de las queries ontolgicas................ 172
5.5.2.3 Fase de inferencias de bsqueda .................................... 173
5.5.2.4 Fase de contacto con el servidor de contenidos educativos
174
5.5.2.5 Fase de descarga............................................................. 174
ndice
5.5.3 Elementos del sistema........................................................ 174

5.5.4 Escalabilidad de la arquitectura ......................................... 176
5.5.4.1 Escalabilidad respecto a la DHT Semntica .................. 177
5.5.4.2 Escalabilidad respecto a la distribucin de contenidos.. 178
5.5.5 Aspectos de seguridad de la arquitectura........................... 181
5.6 Conclusiones .............................................................................. 183
Captulo 6: Especificacin de Ontologa para Interoperabilidad....... 185
6.1 Introduccin ............................................................................... 185
6.2 Visin General ........................................................................... 188
6.2.1 Ontologa para los contenidos estticos ............................. 189
6.2.2 Ontologa para las interacciones alumno-sistema.............. 193
6.2.3 Ontologa para las interacciones entre usuarios................. 197
6.3 Especificacin de una estructura de rbol.................................. 202
6.4 Especificacin de la ontologa para los contenidos estticos..... 208
6.5 Implementacin de la ontologa para las interacciones alumno-
sistema213
6.5.1 Descripcin de las actividades de evaluacin .................... 213
6.5.2 Descripcin de los resultados............................................. 221
6.6 Implementacin de la ontologa las interacciones entre usuarios
224
6.7 Conexin de las tres ontologas ................................................. 229
6.8 Conclusiones de la especificacin.............................................. 230
Captulo 7: Validacin de la Ontologa OWL DL y Resultados ......... 233
7.1 Introduccin ............................................................................... 233
7.2 Generacin de la ontologa propuesta en OWL ......................... 235
7.2.1 Generacin directa ............................................................. 236
7.2.2 Altova SemanticNetworks 2006 ........................................ 236
7.2.3 SWOOP 2.3 beta 3 ............................................................. 238
7.2.4 Protg 3.1.1 ...................................................................... 240
7.2.5 Comparacin de las herramientas ...................................... 243
7.2.6 Generacin de la ontologa ................................................ 244
7.2.7 Chequeo de las ontologa ................................................... 247
7.3 Importacin de los datos reales de foros de experiencias
formativas on-line .................................................................................. 250
7.3.1 Origen de los datos............................................................. 252
7.3.2 Conexin con el origen de los datos .................................. 254
7.3.3 Jena..................................................................................... 255
7.3.4 Programacin de la importacin ........................................ 259
7.3.5 Ejecucin de la importacin............................................... 264
7.3.6 Resultados del proceso de importacin.............................. 265
ndice
7.4 Sistema de bsquedas e inferencias ........................................... 271

7.4.1 FaCT++ 1.1.3 ..................................................................... 273
7.4.2 RACER 1.9 ........................................................................ 274
7.4.3 Pellet 1.3............................................................................. 274
7.4.4 Seleccin del razonador. Comparativa de uso ................... 275
7.4.4.1 Comparativa de caractersticas generales ...................... 275
7.4.4.2 comparativa de rendimientos ......................................... 276
7.4.4.3 Resultados de la comparacin de rendimientos ............. 279
7.4.5 Descripcin del sistema de bsquedas ............................... 284
7.4.6 Carga de conocimientos en el agente................................. 285
7.4.7 Bsquedas por palabras clave ............................................ 287
7.4.8 Inferencias en OWL ........................................................... 288
7.5 Conclusiones de la validacin del sistema................................. 290
Captulo 8: Conclusiones y lneas de trabajo futuras ......................... 295
8.1 Introduccin ............................................................................... 295
8.2 Conclusiones .............................................................................. 296
8.3 Lneas de trabajo futuras ............................................................ 297
8.4 Conclusiones finales .................................................................. 300
Anexo 1. Glosario...................................................................................... 303
Trminos y Acrnimos........................................................................... 304
Anexo 2. Referencias ................................................................................ 309
Artculos e Informes............................................................................... 310
Recursos en Internet............................................................................... 321
ndice
Captulo 1. Introduccin
Captulo 1: Introduccin
1.1 Introduccin
Hoy en da los sistemas Telemticos, y ms concretamente, la World Wide
Web se est introduciendo en todos los aspectos de la vida de las sociedades
avanzadas. Desde consultar cuentas bancarias, a reservar vuelos
directamente a las compaas, obtener las ltimas noticias, incluso tener una
conversacin sncrona o asncrona con los amigos. Otro aspecto ms en el
que est introducindose es en el educativo, y en concreto en las
Universidades, donde el impacto ser an mayor cuando las generaciones
que fueron al colegio con Internet en casa lleguen a la Universidad.
Las tendencias actuales en Teleeducacin se centran en la reutilizacin de

los contenidos (utilizando los llamados Objetos Educativos), ya que tras un
periodo eufrico en que todos los contenidos on-line se generaban desde
cero, se ha llegado a un punto de madurez donde se ha advertido el gran
coste de recursos que conlleva la generacin de un material on-line de
1
calidad desde cero frente a la reutilizacin de contenidos de calidad

generados anteriormente y cuya adaptacin a las nuevas necesidades sea
factible.
Adems, para conseguir dicha re-usabilidad se han de generar mecanismos

que permitan buscar los Objetos Educativos que sirvan para nuestros
propsitos. La ardua tarea de bsqueda de los Objetos Educativos debera
poder desarrollarse mayoritariamente por parte de sistemas no humanos, es
decir, Agentes Inteligentes que puedan entender la meta-informacin sobre
los Objetos Educativos y presentar uno o un conjunto de ellos que cumpla
las expectativas planteadas.
Entendemos como Agente Inteligente [RUS96] a toda entidad que percibe y

acta sobre un entorno. El entorno que trataremos en esta Tesis ser
Internet, y pretenderemos que los Agentes acten sobre el entorno
desarrollando un cierto grado de inteligencia. Todo agente dispone de unos
perceptores, que le permiten recoger informacin sobre el entorno, y de
unos actuadores por medio de los cuales produce modificaciones en el
entorno que le permiten conseguir o acercarse a un objetivo.
Un Agente Inteligente desarrolla, en mayor o menor medida, las siguientes

caractersticas ms destacables para conseguir sus objetivos [JUL00]:
Continuidad temporal: un Agente se desarrolla normalmente por
medio de procesos que tienen una duracin ilimitada. Esta
caracterstica permitir que los Agentes estn continuamente
relacionndose con el entorno.
Autonoma: que indica que no necesita rdenes directas de los
usuarios, sino que muchas veces es el entorno y su propia
experiencia lo que le provoca la realizacin de una accin. Cuanto
ms autnomo sea un Agente para cumplir sus objetivos, menos
esfuerzo demandar de parte del usuario, que podr centrarse en
otras tareas.
Sociabilidad: un Agente se puede comunicar con otros agentes
heterogneos de su entorno, generando en cierto modo un sistema
multiagente. Esta caracterstica se desarrolla de una forma ms
eficaz en arquitecturas con una gran escalabilidad y puede conllevar
tambin la relacin entre Agentes de las mismas caractersticas, lo
que puede generar una red entre iguales o Peer to Peer (P2P).
Racionalidad: que indica que un agente es capaz de realizar las
acciones correctas basndose en los datos que obtiene u obtuvo del
2
entorno. Para conseguirlo se basa en otras caractersticas como la

adaptabilidad y autonoma.
La definicin de Agente Inteligente no indica el grado de inteligencia que

debe desarrollar el mismo, encontrando distintos niveles de elaboracin a la
hora de desarrollar la mencionada inteligencia. Si simplemente buscan
palabras en los documentos, en lugar de aplicar sistemas de agentes ser
mejor utilizar motores de bsqueda ya existentes, como Google o incluso
Gnutella, que nos permitiera alcanzar gran cantidad de elementos que
debera revisar una persona para indicar cul es el que queremos de verdad.
Estos sistemas de indexamiento de palabras clave con una cierta jerarqua en
la que los trminos ms generales tienen como hijos a los trminos ms
especficos se conoce como sistemas Tesauros [GAR04].
En los sistemas de bsqueda actuales, se ha generalizado la tendencia a

definir metadatos sobre los objetos educativos, siguiendo una sintaxis
estndar para colocar los datos y recursos. El lenguaje ms utilizado en el
entorno de Internet para la comunicacin de los metadatos es el Extensible
Markup Language XML [RFC3023], lenguaje fruto de una simplificacin
del lenguaje Standard Generalized Markup Language SGML [ISO8879].
Sobre XML se empieza a trabajar con lenguajes que nos permiten adems
relacionar datos y recursos, siendo el ms aceptado el lenguaje Resource
Description Framework (RDF). RDF sin embargo no tienen la riqueza
semntica necesaria para poder definir una lgica y ontologa completa, por
lo que las ontologas implementadas en RDF necesitan de especificaciones
para programadores en cada caso, que sientan las bases de una lgica y
ontologa inherente pero no entendible directamente por Agentes.
Sin embargo, ahora se est empezando a probar seriamente la introduccin

de lenguajes ontolgicos, que no slo describen recursos colocndoles datos
y relacionndolos, sino que tambin describen de forma estndar las
relaciones entre los distintos recursos a nivel de clases, subclases y adems a
nivel lgico, utilizando la Lgica Descriptiva.
En estos ltimos aos se est afianzando el lenguaje de descripcin de

Ontologas por la Web (OWL, Web Ontology Language), procedente del
trabajo colaborativo entre investigadores americanos y los europeos, que ya
est utilizndose para la descripcin general de Servicios Web (OWL-S)
[ANK04], as como en campos como la medicina con bastante xito
[STE04]. OWL es un lenguaje ontolgico construido sobre RDF/XML y
que fusiona las caractersticas de DAML y de OIL, y que nos permite
3
trabajar con Lgica Descriptiva (en su versin OWL DL) y que se est
erigiendo como estndar para el desarrollo de razonadores de esta lgica. Si
XML nos permite definir clases y los datos de objetos de esas clases y RDF
nos permite incluir sintcticamente relaciones entre los recursos, OWL nos
permite incluir, de forma estndar, las relaciones de una ontologa a nivel de
especializaciones (clases y subclases) y ciertas relaciones lgicas entre ellas,
como definir una clase como la interseccin de otras clases.
Por otra parte, otra tendencia detectada en las herramientas de

Teleeducacin actuales es su enfoque hacia las interacciones que realiza el
estudiante con los otros actores de su experiencia educativa (foros, blogs,
correos electrnicos, calendarios, chats, herramientas colaborativas,
preguntas y exmenes). Esta tendencia contrasta con el inters que exista en
el pasado que se centraba en la generacin de contenidos estticos, y dejaba
a un lado la parte colaborativa, tratndola como un servicio colateral
totalmente separado de los contenidos.
Es decir, las nuevas tendencias de Teleeducacin dan ms importancia a

todo lo que diferencia un verdadero sistema teleeducativo de un simple libro
o un CD con contenidos multimedia estticos. Estos enfoques pretenden dos
objetivos determinados: por un lado incentivar el inters del alumno por
medio de su integracin activa en el proceso educativo y por otro lado
potenciar el enfoque constructivista de la educacin, llegando incluso a
impulsar el denominado aprendizaje indirecto [FOWL05], es decir, el
aprendizaje por el contexto dejado por otras experiencias educativas.
1.2 Motivacin de la Tesis

Podemos decir que la teleeducacin ha pasado por varias fases: una inicial
de experimentacin, donde aparecen gran cantidad de soluciones para los
mismos problemas, fomentada por grandes inversiones a fondo perdido
(proyectos Europeos y proyectos americanos de investigacin) y que nos
deja una gran cantidad de soluciones, la mayora vlidas pero incompatibles
entre s y con escasa aceptacin en el mercado.
Despus, en una segunda fase, basndose en la experiencia y viendo lo

complicado que es generar contenidos de calidad, aparece la necesidad de
exportacin/importacin (necesidad creada muchas veces por los mismos
inversores, como el Ministerio de Defensa de los Estados Unidos) de
recursos educativos (interoperabilidad), con lo que aparecen varios
estndares con el objetivo de recoger casi todas las posibilidades y permitir
un intercambio eficiente de contenidos. Para facilitar dicho intercambio
4
aparece la necesidad de marcar los objetos educativos por medio de

metadatos que los describan y permitan escogerlos e instalarlos en los
nuevos sistemas. Los propios metadatos facilitan a su vez la instalacin en
los nuevos sistemas, ya que normalmente incluyen informacin lgica
sobre el objeto educativo (estructura, navegabilidad, evaluaciones, etc.). De
nuevo para esta segunda fase se parte primero de lenguajes de descripcin
de tipos de datos enviados y estructura de esos datos, como el XML (que ya
tiene herramientas maduras para creacin y modificacin de documentos,
absorcin de informacin y bsqueda). Estos lenguajes dejan la lgica y las
relaciones entre los recursos menos definidas, de forma que en cada
estndar se define una ontologa particular que han de conocer los
programadores.
Pero ahora se plantea la necesidad de agentes de bsqueda ms inteligentes

y por tanto la necesidad de pasar a una tercera fase, con el uso de lenguajes
ontolgicos que permitan que sean los agentes inteligentes los que entiendan
la lgica y sepan ampliar su base de conocimiento por medio de documentos
RDFS (sobre el que se van describiendo ya ms estndares y hay algo de
madurez en herramientas para su tratamiento), OWL o en un futuro SWRL.
Por tanto, lo que nos motiva a la realizacin de dicha Tesis es contribuir al

desarrollo de una tercera fase, por medio de la especificacin de
arquitecturas y agentes de bsqueda para objetos educativos descritos por
medio de la lgica descriptiva. Adems desarrollaremos el enfoque
constructivista de los objetos educativos, es decir, la descripcin de las
distintas interacciones entre los participantes (alumnos, profesores y tutores)
del proceso teleeducativo.
1.3 Objetivos
La presente Tesis pretende estudiar y aplicar las dos tendencias comentadas
anteriormente:
Los objetivos generales de esta Tesis son:
Estudiar y aplicar las nuevas tendencias en interoperabilidad de

recursos educativos, por medio de los lenguajes ontolgicos. Estos
lenguajes estn influyendo a toda la Web en el desarrollo de la Web
Semntica, pero nosotros nos centraremos en el mbito de los
objetos educativos.
5
Incluir en la descripcin de los objetos educativos las

interacciones de los usuarios, pretendiendo ir ms all de la
facilitacin de la interaccin y permitiendo el almacenamiento de
dicha interaccin para su uso posterior, por medio de bsquedas
inteligentes o como parte que ha enriquecido los contenidos con
informacin contextual.
Contribuir al desarrollo y mejora de los sistemas de

Teleeducacin, por medio de sistemas que permitan bsquedas ms
inteligentes que simples tesauros y aadiendo informacin
constructivista.
Impulsar el uso de la Web Semntica en Teleeducacin. Este

objetivo se debe a mi inters sobre Internet y las nuevas
posibilidades que va ofreciendo, desde los laboratorios de
simulacin por medio de applets de Java [ROM 99], [RAG002],
hasta los estndares de transmisin de datos por medio de la Web
como XML [MAN02]. En estos momentos es necesario que la
teleeducacin d un paso ms y aada lgica a la descripcin de sus
recursos, desarrollndose dentro de la Web Semntica.
Estudiar las posibilidades de agentes inteligentes en la

Teleeducacin. Estos agentes son los que revolucionarn la futura
web semntica.
Siendo los objetivos especficos los siguientes:
Mostrar el estado del arte en la Teleeducacin basado en la Web

Semntica, as como presentar fuentes de informacin que permitan
una actualizacin continua en las ltimas tendencias.
Estudiar las ontologas educativas existentes ms importantes.

Para hacer esto revisaremos las bases lgicas en las que se basan.
Describir las interacciones ms importantes que se producen en

un proceso educativo por Internet. Esto nos permitir abstraer las
caractersticas principales de las mismas para el desarrollo de la
ontologa.
6
Definir, desarrollar y evaluar una ontologa para educacin que

permita la reutilizacin y comparticin de recursos educativos,
orientndose a su vez hacia unas tcnicas instruccionales
constructivistas.
Expresar dicha ontologa en OWL, de forma que pueda ser

aprovechada por los Agentes de propsito general que se estn
utilizando para este lenguaje ontolgico.
Proponer y definir una arquitectura para la web semntica en

teleeducacin que permita el uso y explotacin de la ontologa
definida.
Definir, desarrollar y evaluar un prototipo de agente de

bsqueda en la web semntica, basado en la arquitectura
propuesta, que nos facilite la interoperativilidad entre objetos
educativos.
1.4 Principales aportaciones

Los objetivos planteados en esta Tesis generan las siguientes aportaciones al
campo de estudio tratado, que hasta donde llega mi conocimiento no han
sido desarrollados:
Primeras integraciones de las interacciones de los actores de una

experiencia educativa en la parte de interoperabilidad de objetos
educativos. Esto supone un salto respecto a las teoras actuales de
interoperabilidad a nivel de contenidos estticos, que abarcan a lo
sumo en algunos casos a las evaluaciones. Aunque en algunos casos,
como en las evaluaciones, existen ejemplos en XML y XML/RDF,
nuestras propuestas se realizarn sobre OWL DL.
Propuesta, implementacin y evaluacin de una ontologa de

educacin dedicada a las interacciones comentadas en el punto
anterior, llegando a su implementacin y uso en casos y
comunidades de aprendizaje reales.
Propuesta, implementacin y uso de un prototipo de

exportacin de interacciones a un lenguaje ontolgico de lgica
descriptiva (OWL DL). Esto nos permitir definir sistemas que no
empiezan desde cero, sino que son capaces de extraer la informacin
7
necesaria de experiencias educativas ya existentes, y por tanto

facilitar la actualizacin de un sistema a otro.
Desarrollo de tcnicas de extraccin de la informacin

importada a la lgica descriptiva. En estos casos se experimentar
con protocolos que nos permitan atacar a distintos razonadores,
como el caso de DIG (Description Logic Implementation Group
Interface).
Propuesta de arquitectura de explotacin de la interoperabilidad

conseguida por medio de la ontologa propuesta, ampliando
propuestas actuales basadas slo en los contenidos estticos.
Adems, dicha arquitectura se basar en sistemas descentralizados
P2P.
Demostracin por medio de prototipos del uso de las

herramientas actuales as como indicaciones respecto a sus
rendimientos. Esto permite hacerse una idea de las dificultades y
ventajas del uso de estas tecnologas, as como obtener medidas de
rendimiento que nos permitirn compararlas con otras tcnicas ms
bsicas.
1.5 Retos encontrados

Roal Amudsen nunca hubiera conquistado el polo sur si se hubiera retirado
ante los retos que planteaba su expedicin, que nadie antes haba realizado y
para la que no se contaba con equipamiento ptimo y probado. Hoy en da
visitar el polo sur es, aunque difcil, bastante ms sencillo que en 1911.
Una de las limitaciones inherentes a la novedad de los temas tratados en la

Tesis es la falta de herramientas probadas y optimizadas para la validacin
del prototipo, as como la inexistencia de metodologas definidas de trabajo
para interconectar dichas herramientas. Adems, una vez planteada la
ontologa, no se han encontrado arquitecturas probadas y escalables para su
uso.
En este caso particular se ha detectado una falta de herramientas

optimizadas, fciles de usar y compatibles para el trabajo con el lenguaje
ontolgico elegido (OWL), as como de motores de inferencias optimizados
y preparados para la interconectividad. Este problema se ha resuelto por
medio del uso de distintas herramientas, cada una para una determinada
8
parte del estudio, interconectadas de forma manual o por medio de

estndares de comunicacin (DIG, o el propio OWL).
Esta falta de herramientas maduras ha sido un reto que se ha tenido que

vencer por medio de implementaciones propias, el uso de varias
herramientas en desarrollo y la realizacin de comparativas de las mismas.
La inexistencia de arquitecturas optimizadas para el uso de ontologas en la

web semntica nos ha conducido, a su vez, a la definicin de una
arquitectura que supla la carencia en el campo de estudio.
A su vez, el trabajo con la parte de conocimiento no explcita (es decir, el

contexto del curso en lugar de los contenidos estticos generados por el
autor) nos ha planteado dificultades para su esquematizacin, debido a su
inherente falta de estructura fija, as como la necesidad del uso de datos
reales para su experimentacin. Para resolver esta parte se ha planteado una
estructura abierta de ontologa de interacciones, con pocas reglas que
permitan su mxima interoperabilidad.
La necesidad de datos reales para el estudio se ha resuelto gracias a la

experiencia del Centro de Formacin Permanente de la Universidad
Politcnica de Valencia, que ha dejado a la disposicin de este estudio toda
la informacin contextual real de varias comunidades virtuales llevadas a
cabo en aos anteriores.
1.6 Alcance de la Tesis

Como en todo desarrollo que pretenda ser realista, es necesario delimitar el
alcance de esta Tesis y centrarse en la finalidad para la cual ha sido
concebida, de modo que podamos conseguir los objetivos propuestos. En un
campo tan amplio como la propia web, desarrollo de ontologas y los
agentes inteligentes, debemos enfocar nuestro trabajo en reas concretas y
determinadas, especialmente en aquellas donde se tratan los aspectos
realmente innovadores.
Formularemos una ontologa completa sobre las principales reas de una

experiencia educativa por internet, y para realizar una prueba de concepto
trataremos con la parte que no se contempla en la mayora de las ontologas
similares. Esta parte ser la relacionada con los foros, elementos novedosos
en una ontologa y sobre los que existen escasos estudios al respecto.
Asimismo los foros constituyen una de las partes ms complejas de
9
modelizar, implementar y evaluar su rendimiento en bsquedas, siendo las

otras partes de la ontologa ms sencillas a la hora de realizar estas tareas.
Especificaremos adems una arquitectura de explotacin completa,

indicando todos los elementos que intervendrn en dicha arquitectura para
facilitar la publicacin de informacin y el tratamiento de la misma por
parte de los agentes inteligentes. Asimismo, centraremos los ejemplos de
implementacin en la parte realmente innovadora de extraccin de
informacin de las comunidades virtuales actuales y la consulta de dicha
informacin por medio de un prototipo de agente de bsqueda.
Respecto a las tcnicas de extraccin de la informacin de las interacciones

se definir un caso prctico slo a modo de ejemplo. Dicho sistema de
extraccin permitir interactuar con el sistema de informacin del Centro de
Formacin Permanente de la Universidad Politcnica de Valencia, si bien
casi todas las herramientas bsicas de interaccin de los distintos sistemas
de gestin de aprendizaje son bastante similares. La eleccin de este
ejemplo es debida a que disponemos de los permisos necesarios para extraer
datos reales de experiencias educativas que han tenido lugar en el pasado
1.7 Organizacin de la memoria

En este primer captulo se han introducido los principales factores que
motivan la realizacin de esta Tesis, as como los objetivos que se pretenden
alcanzar. El resto de la memoria se desarrolla por medio de captulos tal y
como se indica a continuacin.
En el captulo 2 se realiza un estudio del estado del arte de la web actual,

hablando de los pasos desde el pasado de la web esttica, al presente de la
web dinmica y web 2.0 y el futuro con la web semntica. Dedicaremos
gran parte del captulo a la web semntica y la estructura de capas, ya que es
uno de los pilares sobre los que se construye esta Tesis.
A continuacin, en el mismo captulo, se realiza un estudio del estado del

arte en ontologas de teleeducacin existentes, comenzando con una
descripcin de las principales teoras de aprendizaje, describiendo luego las
principales iniciativas en teleeducacin y las principales ontologas en este
campo. Se completa despus un estudio ms minucioso sobre los foros,
dejando patente la falta de ontologas que cubran este campo.
En el captulo 3 se trata la lgica, los lenguajes lgicos y su relacin con la

web semntica. En una primera parte se sientan las bases lgicas de forma
10
incremental, comenzando por la lgica proposicional, luego la lgica de

primer orden (FOL) y terminando en la lgica objetivo de esta Tesis, la
lgica descriptiva (DL). En esta parte se trata el concepto de suposicin de
mundo abierto (OWA) y el concepto de razonamiento, presentando adems
mtodos para realizar dichos razonamientos. Estos conceptos son necesarios
para la implementacin de agentes inteligentes que se basen en la web
semntica.
En la segunda parte del captulo se estudian los principales lenguajes

ontolgicos, y llegaremos a las tendencias actuales de utilizacin del
lenguaje web para ontologas (OWL), siendo este otro de los pilares de esta
Tesis. Para desarrollar los conceptos de OWL hablaremos de los distintos
niveles de OWL y sus implicaciones respecto a la riqueza descriptiva del
lenguaje y la carga computacional de los razonamientos. Tambin
introducimos los distintos constructores y axiomas utilizados en OWL.
Ya en el captulo 4 comenzamos a presentar las primeras aportaciones de

esta Tesis. Tras describir las interacciones de tipo evaluacin en la
teleeducacin, se estudian la implementacin y metadatos utilizados por el
estndar ms utilizado en evaluaciones, IMS QTI, comparndolo con
nuestra aplicacin basada en XML para la realizacin de exmenes, que
incluye una especificacin de los metadatos (TeML). En este punto se
compararn algunos aspectos de las dos especificaciones. La parte de
nuestra ontologa final relacionada con las evaluaciones se basa en estas dos
especificaciones, que se complementan entre s.
En el captulo 5 se define una arquitectura implementable en la web actual

sobre la que podran correr nuestras aplicaciones utilizando la ontologa
implementada en esta Tesis. Esta arquitectura es un desarrollo
completamente nuevo y que no ha sido tratado de esta forma hasta donde
llega mi conocimiento, y se basa en los conceptos de red Peer to Peer (P2P),
las tablas de hashtables dinmicas (DHT) y la web semntica. Esta
arquitectura se ha bautizado con el nombre de DHT Semntica, y permite no
slo el funcionamiento de nuestros agentes y nuestra ontologa, sino
cualquier sistema basado en agentes inteligentes que funcionen con OWL,
que necesiten una gran escalabilidad.
A lo largo del captulo tratamos la descripcin de funcionamiento y

elementos de la DHT Semntica, as como los conceptos de escalabilidad y
seguridad, conceptos crticos en toda aplicacin web de cierta envergadura.
11
Despus de definir una arquitectura sobre la que se desarrollar el sistema,

pasamos en el captulo 6 a especificar formalmente una ontologa
especialmente diseada para la interoperabilidad. En este apartado
definimos por separado las sub-ontologas para contenidos estticos,
evaluaciones e interacciones entre usuarios, como son los foros. Despus se
fusionan las subontologas en una ontologa global, explicando los puntos de
interconexin entre las subontologas.
Cabe destacar que, aunque existen especificaciones para la

interoperabilidad, no existen especificaciones completas que incluyan los
contenidos estticos y las interacciones, no existiendo tampoco actualmente
ninguna especificacin basada en OWL y preparada para ser atacada por
agentes inteligentes genricos.
En el captulo 7 pasaremos a la fase de validacin de la ontologa y

obtencin de resultados. El objetivo de este captulo es realizar un conjunto
de prototipos que nos permitan realizar una prueba de concepto sobre la
ontologa definida. La primera parte de la implementacin consiste en la
generacin en OWL de la ontologa definida en el captulo 6. Para realizar
esta parte se evalan las herramientas de generacin de ontologas en OWL
principales. Una vez generada nuestra otologa en OWL se comprueba la
correccin lgica de la misma por medio de la clasificacin y el chequeo de
consistencia.
Ms adelante, dentro del mismo captulo, se describe el proceso de

importacin de datos del sistema de informacin del que obtenemos los
datos reales de foros, a nuestra ontologa descrita. Cualquier importacin
desde otro sistema de informacin seguira un proceso similar, utilizando
probablemente las mismas herramientas. Se realizan evaluaciones de
rendimiento en la importacin que nos permiten evaluar la escalabilidad en
la importacin y la complejidad computacional.
Como parte final del captulo 7 se realiza una prueba del uso por medio de
un modelo de agente inteligente, evaluando primero los principales
razonadores o motores de inferencia actuales y modelizando despus la
carga de conocimientos en el agente. Tambin se realizan pruebas de
bsquedas por palabras clave o bsquedas por medio de inferencias. Por
medio de esta prueba de concepto se valida que la ontologa definida en esta
Tesis es implementable y utilizable por medio de agentes inteligentes.
12
Por ltimo tenemos un anexo con el glosario de trminos utilizados, para

facilitar la lectura y comprensin de la memoria, y un anexo con el
conjunto de referencias utilizadas en la memoria.
13
14
Captulo 2. Estudio del Estado del Arte
Captulo 2: Estudio del Estado

del Arte
2.1 Introduccin
En este captulo se estudian las tendencias actuales en el desarrollo de la
web actual, tanto a nivel general como respecto al campo de la
teleeducacin.
A lo largo del captulo nos situaremos en los ltimos desarrollos en los

campos anteriormente mencionados, lo que nos permitir construir a partir
de ese punto para obtener resultados realmente innovadores, mostrando que
hasta la fecha y hasta donde llega nuestro conocimiento no han sido
tratados.
15
Tambin nos permitir este captulo entender mejor el enfoque para los
captulos posteriores, donde se habla de tendencias construccionistas y sobre
todo de desarrollos para el nuevo concepto emergente de web semntica.
2.2 Estado del arte de la Web actual. Web Semntica

2.2.1 Introduccin
Los servicios y utilidades ofertados en la web estn aumentando y esto est
conllevando asimismo que la cantidad de informacin disponible a los
usuarios tambin se incremente.
Un ejemplo de la importancia de la web como fuente de informacin sera la

Tesis que nos ocupa. Las visitas que se han realizado a diferentes bibliotecas
para recabar informacin en el proceso de elaboracin de esta Tesis han sido
ms bien escasas. En cambio, las consultas que se han realizado a la web
han sido numerosas, ya que adems de permitirnos obtener en tiempo real
una informacin variada, nos ha facilitado el acceso a fuentes de
informacin actualizadas. As hemos podido consultar artculos antes de que
se publicaran en sus correspondientes revistas.
Asimismo, el uso de la web como fuente de informacin ha permitido dirigir

el sentido de las bsquedas en funcin de la informacin que se iba
obteniendo. En este sentido se han realizado ampliaciones, se ha
profundizado en nuevas lneas de investigacin que han ido surgiendo a
cada paso; todo ello de una forma rpida y funcional
Otra de las ventajas de la utilizacin de la web es que ha permitido el acceso

a recursos de informacin variados, que no se pueden encontrar en formato
fsico y que en ocasiones han hecho posible incluso un intercambio de
opiniones y una realimentacin que ha enriquecido el resultado final del
trabajo. Nos referimos a la participacin en discusiones por medio de foros,
al uso de listas de inters relacionadas con los temas desarrollados en la
Tesis [WWW73], [WWW74].
Adems, ha sido posible consultar de forma inmediata definiciones e

informacin bsica cada vez que ha ido surgiendo un concepto nuevo a
medida que avanzaba la investigacin. Estas fuentes de informacin
consultadas merecen un cierto grado de confianza, ya que en el caso de
Wikipedia [WWW67] se indican las definiciones y artculos que han sido
revisadas por diversos actores.
16
Sin embargo no todo han sido ventajas en el uso de la web para la

elaboracin de esta Tesis. En este sentido, la gran cantidad de informacin a
la que se ha podido acceder se ha convertido, en ocasiones, en un
inconveniente, ya que es necesario seleccionar los recursos que nos
interesan y que nos van a ser tiles, y saber diferenciarlos de aquellas
fuentes que no son fiables ni nos aportan datos nuevos. Aunque los ejemplos
son numerosos, citaremos tres de ellos por resultar especialmente
significativos.
Gracias al mundialmente conocido buscador Google [WWW66], que

dispone de ms de dos billones de recursos indexados, no hemos tenido que
rastrear toda la web en busca de informacin, pero s nos hemos visto
obligados a cribar toda la que bamos obteniendo. Esto es as porque este
buscador nicamente permite realizar consultas simples y basadas en el
contenido de texto, de forma que por cada entrada se han obtenido
cantidades ingentes pero inoperantes de recursos relacionados.
Si bien es cierto que este buscador sita en las primeras posiciones los
recursos ms referenciados, ello no ha evitado que se haya tenido que
revisar muchos de los recursos de forma manual en un proceso minucioso.
Algunos recursos se caracterizaban por tener contenidos de gran calidad, y/o
haban sido desarrollados por personalidades de reconocido prestigio en la
temtica; pero en otros casos no era as, o bien los recursos contenan
informacin repetida o se centraban de un modo secundario en la temtica,
de modo que ha habido que desecharlos
Otro ejemplo de sobreinformacin se ha producido con el uso de Citeseer

[WWW9], que aunque se basa en la metainformacin para realizar
bsquedas, tiene un alcance limitado.
Por su parte, los foros y listas de distribucin, han permitido encontrar

respuesta a algunas de las dudas e inquietudes que se han planteado en el
proceso de elaboracin de esta Tesis, y conocer las experiencias similares a
las que se han enfrentado otros investigadores. Sin embargo, se han recibido
ms de 1.000 correos al mes en algunas de las listas de inters, lo que nos ha
obligado nuevamente a realizar un elaborado proceso de seleccin, ya que
no podamos, por razones obvias de limitacin temporal, acceder a todos
estos contenidos.
Luego, en este ocano infinito de informacin en crecimiento vertiginoso

que es la Web, necesitamos disponer de las herramientas adecuadas para
17
acceder a aquellos recursos e informaciones que realmente nos interesan de

una forma eficiente. Estas herramientas, para que realmente sean tiles,
deberan ser capaces de desarrollar cierta inteligencia que nos permitiera
acotar las bsquedas que queremos realizar. Para ello, una gran parte de la
informacin que podemos encontrar en la web debera ser entendible por las
mquinas de forma que stas pudieran evaluar la calidad y adecuacin de los
contenidos a las necesidades del usuario.
En los siguientes apartados se muestra el grado de desarrollo y de

preparacin que ha alcanzado la web actual, para que en ella puedan realizar
las mquinas bsquedas inteligentes. Se parte de la web sintctica para
comentar la web ms dinmica llamada web 2.0 y por ltimo la web
semntica. El apartado de la web semntica se desarrollar a fondo
explicando las capas en las que se basa, ya que va a ser uno de los puntos
fundamentales de esta Tesis.
2.2.2 Web Sintctica

La Web, como la conocemos actualmente se puede considerar como una
Web sintctica: un lugar donde los ordenadores se encargan nicamente de
la tarea de transmisin y presentacin de los recursos. Por otro lado, son los
usuarios los encargados de realizar las distintas interpretaciones de los
recursos presentados y de relacionar los recursos entre s de forma lgica.
Estas tareas que han de realizar los usuarios son costosas sobre todo con la
gran cantidad de informacin disponible actualmente en la web [GOB03].
Otros autores denominan a este estadio de la web como Web 1.0 [ORE05].
Basndonos en una web con estas caractersticas, se puede exigir poco a los
sistemas de bsqueda automticos. A lo sumo se pueden realizar sistemas
que busquen palabras o conjunto de palabras, ordenados en funcin de la
importancia que dan otras personas a ese recurso por medio de las veces que
se encuentra dicho recurso como hipervnculo en otros recursos. Google
trabaja de esta forma, por medio de indexaciones y asignaciones de peso de
importancia segn las veces que sea referenciado un recurso en otros
recursos. Pongamos por ejemplo la bsqueda de recursos que contengan el
texto Semantic Web, y probablemente obtendremos la pgina oficial de
dicha iniciativa en W3C como una de los primeros resultados de la
bsqueda.
Sin embargo, estos sistemas de bsqueda estn incapacitados para la

bsqueda de recursos con unas caractersticas lgicas ms complejas. Por
ejemplo, sera imposible solicitar al sistema el conjunto de artculos que
18
traten como tema central la Web Semntica y que estn escritos por autores
prestigiosos en ese campo. La razn estriba en que la informacin que
tienen y pueden entender las mquinas en la web sintctica es informacin
de cmo presentar el recurso, e hipervnculos a recursos relacionados. El
contenido semntico (si es un artculo, si trata principalmente de la Web
Semntica, si el autor est dentro de los prestigiosos) slo es entendible por
los humanos.
Un concepto distinto al de la web sintctica y que no podemos confundir es

el de web esttica. Una web esttica es una web de un servidor que presenta
contenidos prefijados de antemano y que no varan en funcin de las
peticiones de los usuarios y de la informacin que se disponga en cada
momento. En estos casos lo nico que define de forma completa el
contenido a presentar es la direccin URL que solicita el usuario.
En oposicin a la web esttica se encuentra el concepto de web dinmica, en

la que los recursos y contenidos que presenta el servidor a cada usuario son
variables, ya no dependiendo solamente de la URL que solicita el usuario,
sino de otros parmetros. Uno de estos nuevos parmetros que varan los
contenidos presentados es la informacin que dispone el servidor en el
momento en que se solicita el recurso, como ocurre cuando se consulta
informacin meteorolgica de un lugar. Otro posible parmetro puede ser el
usuario que accede al recurso, en caso que se haya identificado, teniendo
como ejemplo en este caso cualquier aplicacin web de lectura de correo
electrnico. Otro posible parmetro a tener en cuenta es informacin extra
enviada por el solicitante del recurso incluida en la propia URL (mtodo
HTTP/GET) o de forma separada (mtodo HTTP/POST).Esta informacin
extra la suele introducir el usuario por medio de formularios que aparecen
en la web. Normalmente las webs estticas basan su informacin en un
conjunto de ficheros situados en directorios y las webs dinmicas procesan
adems informacin proveniente de bases de datos, ya sean monolticas o
distribuidas.
Las webs dinmicas y estticas pueden aparecer dentro de la web sintctica,

ya que el concepto de dinmico o esttico slo se refiere a la forma de
generar los recursos, no a la utilidad de los mismos.
2.2.3 Web 2.0

Web 2.0 [ORE05] es un trmino que se extendi a finales del 2004, y que
en principio intenta agrupar un conjunto de nuevos servicios y tecnologas
que estn emergiendo en la Web. Sus bases son:
19
La web es la nica plataforma. Toda accin sobre los sistemas se

realiza va web, por medio de navegadores estndar, sin instalar
nada. Este punto rompe con la tendencia clsica de generar
programas que se tengan que instalar en los ordenadores de los
usuarios, ya que pasamos a ofrecer servicios por medio de la web a
cualquier usuario que tenga un navegador.
Como principal ventaja de esta decisin tenemos que siempre

disponemos del servicio actualizado, y que los programadores no
han de preparar un conjunto de versiones instalables distintas para
los distintos sistemas operativos. Adems, a nivel comercial se deja
de ofrecer un programa que se ha de instalar y mantener en cada
usuario y en su lugar se ofrece un servicio que se puede dar de alta o
de baja de forma inmediata para cada usuario.
Como principal crtica tenemos que no podemos aprovechar todo el

potencial que tiene programar para un sistema operativo
determinado, y que las acciones que podemos realizar sobre el
ordenador del usuario son ms limitadas. Estos tipos de crticas son
similares a las que se realizaron cuando se dej de programar en
cdigo ensamblador para todas las aplicaciones. Hay una gran
cantidad de aplicaciones que no demandan todo el potencial de las
mquinas de los usuarios y su desarrollo ms ptimo es el que se
desarrolla por medio de servicios web.
Uso de tecnologas Rich Internet Aplication (RIA), que se basan en

simular la mayora de funcionalidades de aplicaciones locales que
ejecutaramos normalmente desde nuestro ordenador. Suelen
potenciar la ejecucin en el cliente dentro de un contexto cerrado y
limitado denominado sandbox. De esta forma las aplicaciones sufren
una restriccin de acceso a los recursos locales, Como ejemplo
tenemos la programacin en Ajax (Javascript + CSS , donde el
cliente se comunica con el servidor por medio de XML y recibe
XML que interpreta) o los desarrollos en modelo/vista como los
realizados con JavaServer Faces (JSF). Estas tecnologas suelen ser
ineficaces cuando el usuario tiene un nivel de seguridad alto en su
navegador, de forma que no permite ejecutar comandos en Java,
Javascript o ActiveX. La mayora de servicios extra ofrecidos por
Google se han implementado siguiendo la filosofa de web 2,0,
aunque el buscador no est implementado con esta tecnologa.
20
Focalizacin en la socializacin en la web. Con esta frase nos

referimos a aplicaciones en las que los usuarios participan en la
construccin de los contenidos, por medio de sistemas de
publicacin como pueden ser los blogs. Este apartado tambin se
refiere a aplicaciones en las que los usuarios pueden colaborar entre
s, por medio de aplicaciones colaborativas.
Dentro de las aplicaciones colaborativas se encuentra aplicaciones de

escritura colaborativa como wiki [WWW51]. Tambin incluye
sistemas (como por ejemplo, de sindicacin como RSS) que
permiten la colaboracin de varias webs, de forma que unas se
alimentan de datos de las otras.
El principio por el que se impulsan las aplicaciones en las que

colabora el usuario se basa en que estas opciones ms participativas
implican ms a los usuarios y hacen que aumente el inters de los
mismos en la actividad que se est llevando a cabo por web.
Como podemos apreciar, la definicin del trmino Web 2.0 en s es ambigua

y no define estndares ni pautas fijas para concluir si una web cumple Web
2.0 o no, por lo que algunos autores [WWW70], aunque piensan que las
tecnologas que se utilizan son muy tiles, critican el trmino como un
trmino ms bien comercial al que se adhieren muchos con simplemente
instalar un blog o por programar con Ajax. Estos mismos autores
argumentan que no deja de ser ms que un avance dentro de la web
sintctica, ya que la informacin, excepto la informacin sobre cmo
presentar los recursos, es slo entendible por los usuarios.
2.2.4 Web Semntica

Ya desde los principios de la World Wide Web se pensaba en esto. Debera
haber alguna informacin entendible por las mquinas que permitiera a stas
realizar anlisis ms profundos y ayudarnos a las personas en nuestras
tareas.
Para esto, ya en el ao 1998, [TBL1998] Tim Berners-Lee, uno de los

padres de la Web actual, escribi su visin sobre lo que sera la Web
Semntica. Una nueva forma de contenido en la Web que tenga significado
para las mquinas, que disparar una revolucin de nuevas posibilidades
[TBL2001].
21
Podemos definir la Web Semntica como una meta-web que se construye

encima de la actual WWW [MAE2001]. Se fundamenta en la idea de tener
datos en la Web definidos y vinculados de forma que puedan ser usados por
mquinas no slo a la hora de pintarlo sobre pantalla, sino para tareas de
automatizacin, integracin, interpretacin y reutilizacin de datos a travs
de varias aplicaciones [TBL2001].
El objetivo de la Web Semntica es proveer un marco comn que permita

que los datos sean compartidos y reutilizados por distintas aplicaciones,
compaas y comunidades. Es un esfuerzo colaborativo liderado por W3C
con la participacin de un gran nmero de investigadores y socios
industriales [WWW1]. En siguientes apartado se describe ms a fondo la
Web Semntica.
2.2.5 Estructura de capas

Tim Berners-Lee ha sido el propulsor principal de la Web Semntica como
se entiende en el World Wide Web Consortia (W3C). Las premisas son:
Seguir utilizando la Web actual. Utilizar los sistemas que ya

existen en la Web. Si la Web actual funciona con lenguajes de
marcas (Markup Lenguaje), URIs y los sistemas funcionan
ignorando las marcas que no entienden, la Web semntica ha de
basarse en esos tipos de lenguajes. De esta forma se puede
compatibilizar la Web actual con la semntica, aadiendo a la
primera anotaciones semnticas.
Esto nos permite seguir con la gran inercia que tiene la Web como la
conocemos ahora y aprovecharnos de ella.
Estructura de capas. La mejor forma de reutilizar es apoyarse en

lenguajes conocidos y construir encima de ellos. Esto tambin
conlleva desventajas, ya que en algunos casos se sacrificar
legibilidad por parte de los humanos y optimizacin en la
compresin, a cambio de utilizar lenguajes existentes. Tambin
algunos autores critican la ambigua relacin y separacin entre las
distintas capas [IAN2003].
La estructura propuesta por [TBL2000], es la siguiente (Figura 2.1):
22
VERDAD
PRUEBA
FIRMA DIGITAL
LOGICA
VOCABULARIO ONTOLOGICO
RDF + RDFS
XML + NS + XMLS
UNICODE URI
Figura 2.1. estructura de capas de la Web Semntica
A continuacin explicaremos las distintas capas, y veremos que la realidad

desarrollada vara, sobre todo en las ltimas capas, respecto del modelo
propuesto.
2.2.5.1 Unicode + URI Smbolos e Identificadores de Recursos

Unicode es el estndar de smbolos utilizado, que permite representar textos
en todos los idiomas conocidos, y sin necesidad de inventar reglas auxiliares
para caracteres no americanos.
Podemos definir el standard Unicode como el estndar universal de

codificacin de caracteres usado para la representacin de texto en
computadores. Dicho estndar es independiente del computador utilizado y
la plataforma utilizada, y adems permite la representacin de caracteres de
todas las lenguas escritas del mundo, facilitando la programacin
multiidioma y multiplataforma. Codifica a su vez de forma estndar acentos,
diresis y algunos smbolos matemticos,
Unicode se ha definido de modo que es totalmente compatible con el juego

universal de caracteres definido en ISO/IEC 10646, y crece a partir del
ASCII, amplindolo a alfabetos distintos al americano. Unicode define tres
23
formatos de codificacin a bits, conocidos como Unicode Transformation

Format, UTF-8, UTF-16 o UTF 32, dependiendo de los bits utilizados por
carcter, utilizando UTF 32 tamao fijo para los caracteres y siendo UTF-8
el que permite longitud variable en los caracteres y mayor compresin para
almacenamiento de caracteres ASCII.
Una vez definidos los smbolos sobre los que se construyen las siguientes
capas, se define una capa que nos permite referirnos a un espacio de objetos
o conceptos sobre los que pretenderemos ofrecer informacin, de forma que
los agentes inteligentes sepan a lo que nos referimos. En este caso se recurre
a los identificadores que ya existen en la Web, es decir: Uniform Resource
Identifiers (URIs).
Las URIs conforman un espacio de identificadores, de forma que una URI

[RFC3986] es una secuencia de caracteres que identifica un recurso
abstracto o fsico. Dichas secuencias de caracteres pueden abreviarse por
medio de formas relativas, siendo en todo caso su identificacin inequvoca.
El espacio de identificadores representa con la misma sintaxis a todo tipo de

recurso (lo que le da el carcter de uniforme), y est abierto a la aparicin de
cualquier otro nuevo tipo de recurso.
Las URIs identifican los recursos. Si adems de identificarlos, esa

informacin nos permite localizarlos, hablamos de Uniform Resource
Locators (URLs) [RFC2718].
La principal ventaja de las URIs es que se disearon para la web, por lo que
no tienen por qu ser centralizadas, aunque algunas (por ejemplo las basadas
en http) se basen en sistemas jerrquicos centralizados.
Sin embargo esta especificacin, al carecer de sistemas de control, es

incapaz de asegurar la unicidad de los identificadores. No se puede asegurar
ni rechazar a priori que un par de URIs distintas se refieran al mismo
recurso.
2.2.5.2 XML + NS + XML-s. Capa de Intercambio de datos

Extensible Mark-up Language (XML) es el lenguaje que se ha convertido en
el lenguaje para el intercambio de datos estructurados en la Web. Se basa en
un sistema SGML (ISO 8879), siendo un sistema anidado de marcas.
Actualmente la gran mayora de las Bases de Datos son capaces de aceptar y
producir datos estructurados en forma de XML.
24
La propiedad principal de este lenguaje es la capacidad de transmitir datos

estructurados, adems de definir la estructura que han de cumplir los datos.
Esta definicin de estructuras se realiza normalmente, por medio de
Document Type Definitions (DTDs) o XMLSchemas (XMLSs).
DTD es el documento que define la gramtica de un objeto de datos

definido en un documento XML, y nos permite validar un documento XML.
DTD utiliza una sintaxis distinta a la de los documentos XML. Por otro lado
XMLSchema (XMLS) es un documento que tambin puede definir la
gramtica de un objeto de datos definido en un documento XML, con la
diferencia que su sintaxis coincide con la de XML.
Se puede afirmar que XMLS es un documento XML, que tiene un DTD que
define su gramtica, y cada documento XMLS a su vez define la gramtica
de otros documentos XML. Esto nos permite que, suponiendo que los
procesos disponen informacin a priori de la gramtica nica de los
documentos XMLS, utilicemos el mismo parser para decodificar los datos
de un documento y la definicin de su gramtica.
XML permite que los procesos puedan recibir datos estructurados por medio
de XML, y puedan validar su correccin por medio de su correspondiente
DTD o XMLs para ver si los datos se han generado y recibido de forma
correcta, as como generar una estructura de datos interna igual a la recibida.
Al no haber quedado a priori de acuerdo los programadores sobre cada

estructura de datos en concreto, el lenguaje permite una flexibilidad
necesaria para la Web, lo cual permite definir nuevas estructuras de datos de
forma rpida y descentralizada. Una vez definida una nueva estructura, lo
nico que hemos de hacer es publicarla, ya que todo documento XML
identifica unvocamente la localizacin del documento DTD o XMLs para
su validacin.
Los espacios de nombres, Name Spaces (NS) se definen como una URI que
representa a un conjunto de nombres, dentro de la estructura de datos en la
que estn definidos. A nivel prctico sirven para definir sufijos de URIs, de
forma que un conjunto de trminos comunes y definidos por la misma
entidad compartan el mismo espacio de nombres. Por ejemplo:
<x xmlns:edi=http://ecommerce/schem> [Ej. 2.1]

<edi:bill>1232</edi:bill>
</x>
25
En el ejemplo 2.1 vemos que evitamos la repeticin de la URI completa

<http://ecommerce/schem:bill> y para facilitar su lectura y compactar la
informacin utilizamos en su lugar <edi:bill>.
Los espacios de nombres son de gran importancia para los lenguajes RDF,
RDFS y OWL, ya que cada uno realiza una definicin formal de palabras
reservadas en su sintaxis, creando un espacio de nombres, que a su vez
utiliza los espacios de nombres de los lenguajes de las capas inferiores.
Estos espacios de nombres se obvian a lo largo de toda la Tesis para facilitar
la comprensin de los ejemplos.
2.2.5.3 RDF + RDF+s. Capa de Aserciones.

Resource Description Framework (RDF) es una recomendacin W3C
[WWW2], que permite realizar aserciones. RDF ofrece un modelo para
representar recursos (que pueden ser valores literales como un valor entero),
y relacionarlos entre s por medio de propiedades. RDF pretende describir
recursos, que se representan por medio de URIs, por medio de propiedades
(tambin representadas por URIs). Por tanto definimos una propiedad como
un aspecto especfico, caracterstica, atributo o relacin utilizado para
describir a un recurso. Cada propiedad se corresponder a un significado
especfico, y se definirn los valores permitidos en cada caso y los recursos
a los que puede describir.
Entendemos las aserciones (tambin llamadas sentencias, declaraciones o

enunciados) como el conjunto de un recurso especfico, una propiedad y un
valor de dicha propiedad. Al recurso que describimos lo denominamos
como sujeto, a la propiedad como predicado y al valor de la propiedad como
objeto. Por tanto, entenderemos como aserciones en este caso el conjunto
<sujeto, predicado, objeto>, que puede ser presentado como un grfico.
[Ej. 2.2]
<Pedro, trabajaCon, Juan>
trabajaCon(Pedro,Juan)
Pedro.trabajaCon(Juan)
26
trabajaCon
Pedro Juan
En el ejemplo 2.2 podemos ver tres formas textuales de representar la

misma asercin. Adems se presenta una forma grfica de representacin de
la misma asercin.
Las aserciones describen los recursos (URIs), y se pueden hacer las

aserciones que queramos, para dar ms informacin respecto a los sujetos,
objetos e incluso propiedades (predicados). De esta manera se consigue
describir cualquier recurso, por lo que estamos ofreciendo informacin
respecto al mismo, y as podemos realizar un sistema que proporcione
informacin de forma incremental, asercin a asercin. El recurso que
describamos en una asercin puede ser en principio propiedad de otra
asercin distinta.
Su sintaxis est basada en XML (su capa inferior) y se compone de unas

marcas, describindose los recursos mediante los tags <Description>,
donde el atributo about describe al sujeto y cada elemento dentro de la
descripcin se consideran propiedades de ese sujeto.
<Description [Ej. 2.3]

about=http://www.dcom.upv.es/personal/Pedro>
<trabajaCon
resource=http://www.dcom.upv.es/personal/Juan>
</Description>
Como podemos ver en el ejemplo 2.3, utilizamos la marca <Description>

para enmarcar la asercin, en la que realizamos la misma descripcin que en
el ejemplo 2.2.
RDF es un lenguaje maduro con una gran aceptacin dentro de las

principales entidades relacionadas con la web, y se han desarrollado
27
multitud de herramientas que permiten realizar consultas (queries) sobre la

informacin en RDF o grafos, mediante estndares de acceso a datos RDF
como RDQ, RDQL, SeRQL, SPARQL o N3QL entre otros.
RDF es, adems, un lenguaje extremadamente verstil, demasiado para ser

un lenguaje ontolgico. De hecho, no se reserva palabras clave para
distinguir clases (entendidas como una agrupacin de objetos), y no
distingue entre propiedades y elementos (todo son recursos).
Para resolver esto aparece el RDFSchema (RDFS), que s que incluye

trminos como Class, Property, type, subClassOf, range, domain, de forma
que estn incluidos en la semntica del lenguaje y por tanto podremos
realizar aserciones cuyo significado entiendan los distintos procesos. A
continuacin se presentan algunos ejemplos explicatorios.
<Description [Ej 2.4]

about=http://www.dcom.upv.es/general/SeresHumanos>
<rdf:type rdf:Class>
</Description>
<rdf:Class rdf:resource=
http://www.dcom.upv.es/general/SeresHumanos>
En el ejemplo 2.4 vemos dos formas en las que podemos describir a los
seres humanos indicando que son una clase. La diferencia es que con RDF
se necesita una convencin entre el emisor y el receptor de la informacin
para que sepa la semntica de la propiedad Class, lo que no es necesario en
RDFS por estar incluido ya en el lenguaje.
<Description [Ej. 2.5]

about=http://www.dcom.upv.es/personal/Pedro>
<rdf:type rdf:resource=
http://www.dcom.upv.es/general/SeresHumanos>
</Description>
En el ejemplo 2.5 vemos la descripcin del recurso Pedro, indicando que

Pedro es un (objeto perteneciente a la clase) ser humano.
<rdfs:Property rdf:ID="trabajaCon"> [Ej. 2.6]

<rdfs:domain rdf:resource="#SeresHumanos"/>
28
<rdfs:range rdf:resource="#SeresHumanos"/>
</rdfs:Property>
En este caso vemos que, en el ejemplo 2.6 se indica que trabajaCon es una
propiedad, que relaciona un Ser Humano (sujeto descrito por la marca
rdfs:domain) con otro Ser Humano (objeto, descrito por la marca
rdfs:range).
Aunque RDFS permite desarrollar una cierta ontologa, no hay restricciones

de cardinalidad o existencia. Esta falta de concrecin nos limita la semntica
del lenguaje, impidiendo, por ejemplo, indicar por medio del lenguaje que
todas las personas tienen una madre biolgica, por ejemplo.
2.2.5.4 Capa Ontolgica, capa Lgica, capa de Prueba

En este punto trataremos de forma conjunta las tres capas, ya que la capa
ontolgica es la que enriquece la informacin por medio de una primera
ontologa en la que se pueden describir relaciones de pertenencia a clases e
instancias. Este tipo de aserciones son las que hemos comentado ya resuelve
RDFS.
La capa lgica es la que trata de las relaciones lgicas entre los objetos de
estudio, generando una ontologa ms detallada y completa. Un lenguaje
ontolgico suele dar solucin a estas dos capas, como es el caso de OWL.
Por ltimo la capa de Prueba es donde se realizan las comprobaciones de si

una suposicin es cierta, o se devuelven ejemplos de objetos que cumplan
unas restricciones definidas. Es donde trabajan los razonadores como FaCT
o Racer.
Estas tres capas enumeradas se describirn con mucho ms detalle en los

apartados de Lgica y Lenguajes ontolgicos, donde hablaremos de lgicas,
OWL y razonadores.
2.2.5.5 Capa de Verdad y Firma Digital

La capa de verdad es la que permite decidir qu grado de fiabilidad le
concedemos a nuestro razonamiento, basndonos en la confianza en nuestras
fuentes de informacin. Para obtener una buena deduccin no es suficiente
el uso de un razonador que devuelva soluciones correctas, sino que adems
tenemos que asegurarnos que confiamos en las premisas.
En la Web la forma de confiar en una informacin es:
29
Averiguar de dnde viene realmente la informacin, y que dicha

informacin no ha sido modificada desde que se gener.
Decidir si esa informacin de ese origen en concreto es fiable para

nosotros, normalmente en base a nuestra experiencia o consultado a
un tercero sobre la fiabilidad de la fuente.
Aqu es donde aparece la firma digital, ya que permite a cualquier nivel (en
principio el estndar es a nivel de XML Digital Signature [WWW68])
decidir si esa informacin es realmente de quien dice que es, y evitar
falsificaciones.
Esto nos permitir saber que la informacin viene de donde dice que viene,
o si tiene una firma digital que le ha entregado alguna entidad en la que
confiemos, como Verisign. Tambin existen en la actualidad sistemas
distribuidos de confianza, como el que utiliza PGP [RFC2440].
2.3 Estado del arte en Ontologas para Teleeducacin

2.3.1 Introduccin
En este apartado trataremos la Teleeducacin, entendida como la formacin
a distancia utilizando la web. La Teleeducacin enmarca la utilizacin de
nuevas tecnologas hacia el desarrollo de metodologas alternativas para el
aprendizaje.
Para poder abarcar uno de los objetivos de esta Tesis, que es contribuir al
desarrollo y mejora de los sistemas de Teleeducacin, necesitamos presentar
un estado del arte que nos permita confirmar que esta Tesis completa partes
an no alcanzadas en el campo de investigacin y que van en lnea con las
ltimas tendencias del mismo.
Adems veremos en este apartado las principales teoras sobre el

aprendizaje que definen las distintas formas de que se produzca aprendizaje
en el sujeto que recibe la formacin, ya que cada enfoque recomienda unas
herramientas distintas para que se produzca el aprendizaje. Este punto nos
permite abrir ms las miras de la Teleeducacin basndonos en las races de
los sistemas y mtodos de aprendizaje en s mismos.
Despus presentaremos el significado que tiene la formacin por la web, las

ventajas, y alguno de los inconvenientes que suele acarrear. Continuaremos
30
describiendo someramente las distintas recomendaciones, especificaciones,

modelos de referencia y estndares relacionados con la Teleeducacin,
tratando sobre todo su relacin con las ontologas y los metadatos. Este
apartado, en conjunto con los apartados de aportaciones de la Tesis, nos
permitir ver que se ha cubierto reas todava no tratadas por otros
investigadores de la materia.
A continuacin describiremos la ontologa relacionada con la educacin ms

aceptada, el estndar IEEE-LOM-1484.12.1, y hablaremos de las
posibilidades de la web semntica en la Teleeducacin. Es en s la propuesta
del uso de la Web Semntica para mejorar los sistemas de Teleeducacin
uno de los objetivos principales de la Tesis, y que justifica la posterior
definicin de una ontologa que nos permita este propsito.
Por ltimo describiremos con detalle los foros en la teleeducacin y las

ontologas utilizadas hasta la fecha para los mismos. En este apartado
veremos y justificaremos que para la prueba de concepto de la ontologa,
que llevaremos a cabo en captulos posteriores, se desarrollen ejemplos para
los foros, ya que sta es una de la partes de la ontologa ms novedosa en la
actualidad, pese a que los sistemas de Teleeducacin cada vez enfatizan ms
la importancia de las herramientas que fomentan la participacin e
interaccin de los agentes de un proceso de aprendizaje.
2.3.2 Teoras de aprendizaje

La Teleeducacin se aplica con fines instruccionales, es decir, se aplica
sobre temas que suponemos se pueden ensear a los alumnos. Se distinguen
tres orientaciones del diseo instruccional: Conductismo, Cognoscitivismo y
Constructivismo [NEW96].
2.3.2.1 Conductismo (Behavioral)

Se basa en los cambios observables en la conducta del sujeto, y se enfoca en
la repeticin de patrones de conducta hasta que estos se realizan de forma
automtica.
Esta teora aparece a principios del siglo XX con B.F. Skinner, con sus ideas
del condicionamiento operante. Postula que el aprendizaje ocurre cuando
hay cambios en el comportamiento como respuesta a unos estmulos
externos. Se suelen basar en esta teora los simuladores, que reflejan el
entorno de forma que aprendamos a reaccionar bajo unas condiciones
determinadas.
31
En este caso el profesor disea completamente el entorno educativo y el

alumno es un agente bsicamente pasivo. Se disean unos objetivos del
aprendizaje a modo de comportamientos deseados del alumno, y usa
consecuencias para reforzar el comportamiento.
La evaluacin se suele hacer con tests individuales al final de cada leccin,

que se puede evaluar de forma totalmente objetiva (por ejemplo, en un test,
contando las respuestas acertadas).
2.3.2.2 Cognoscitivismo (Information Processing)

Se basa en los procesos que tienen lugar debajo de los cambios de conducta.
Estos cambios son observables y pueden usarse como indicadores para
entender lo que est pasando en la mente del que aprende.
Esta teora surge a mediados del siglo XX con George Miller, con ideas
como que la mente humana funciona como un computador, cogiendo
informacin, procesndola, guardndola y relocalizndola de nuevo si la
necesita. Esta teora afirma que el aprendizaje ocurre como un cambio en el
conocimiento interno que tiene cada persona, en su memoria.
El alumno realiza tres procesos: atencin (fijarse en los ejemplos),

codificacin-internalizacin (almacenar el conocimiento extrado en nuestra
memoria) y obtener de nuevo ese conocimiento (retrieval) para utilizarlo.
Los ejemplos ms tpicos son los que a partir de ejemplos complejos
ensean la conceptualizacin de un hecho y luego piden al alumno que
explique qu conceptualizacin han obtenido.
El profesor en este caso de dedica a organizar la nueva informacin y a

buscar enlaces con el conocimiento que ya tienen los alumnos, intentando
buscar tcnicas para apoyar la atencin, codificacin y uso del
conocimiento.
Para evaluar que el proceso de aprendizaje es correcto, se le suele pedir al

alumno que esquematice los conceptos que haya abstrado y que los
relacione entre s (por medio de mapas mentales, por ejemplo).
2.3.2.3 Constructivismo
Se sustenta en la premisa de que cada persona construye su propia
perspectiva del mundo que le rodea a travs de sus propias experiencias y
esquemas mentales desarrollados.
32
El Constructivismo se reafirma como teora a finales del siglo XX, y

representa un conjunto de ideas como aprendizaje situacional y aprendizaje
colaborativo.
En este caso el aprendizaje se hace cuando los alumnos construyen nuevas

ideas o conceptos basados en su conocimiento o experiencia anterior (cada
aprendizaje depende del entorno social en el que est el alumno),
resolviendo problemas realistas, normalmente en colaboracin con otros
alumnos.
Las palabras clave en este caso son experiencia y colaborar, y el

profesor ha de plantear problemas realistas, complejos y en los que el
alumno se identifique. Adems ha de impulsar actividades colaborativas
entre los alumnos para que nazca el conocimiento entre ellos.
La evaluacin de esta ltima teora se suele realizar de forma continua,

observado el comportamiento de un alumno en un grupo y evaluando los
distintos proyectos realizados por el grupo.
Como podemos ver esta teora es la que da ms importancia a la actuacin

del alumno, y es la responsable de las teoras de centrarnos en el aprendizaje
de cada alumno ms que en la enseanza impartida por el profesor, como se
hizo para el diseo de los crditos ECTS (European Credit Transfer
System), y de iniciativas para fomentar el aprendizaje colaborativo entre
individuos (P2PLearning).
2.3.3 Teleeducacin
La web es un canal idneo para el aprendizaje por sus caractersticas:
Interconecta la mayora de las fuentes de conocimiento instruccional

(Universidades, Centros de Investigacin, etc.) de los pases
desarrollados.
Interconecta, a su vez, a gran cantidad e potenciales alumnos, que si

son ingenieros, suelen estar muy familiarizados con el uso de
internet.
El uso de la Web est creciendo conforme el ancho de banda va

creciendo y los precios van bajando. En Estados Unidos, por
ejemplo, el ratio de estudiantes por ordenador conectado a Internet
ha mejorado de 20 estudiantes en 1998 a 5.6 en 2002 [ANS03].
33
Por estas razones, la creacin de contenidos para la Web ha ido creciendo

considerablemente, especialmente dentro de las Universidades, siempre tan
vidas de investigar nuevas posibilidades. Sin embargo la mayora de cursos
se han empezado desde cero, y no han podido ser reutilizados para generar
otros cursos relacionados.
El coste de crear contenidos es muy alto [SOE96], entre otras cosas porque
la formacin va web deja poco espacio para la improvisacin por parte del
profesor, y esto obliga a generar contenidos muy bien definidos y
estructurados. Este alto coste nos hace que con slo una edicin del curso no
se amorticen normalmente los gastos de produccin, y que la reutilizacin
sea uno de las principales metas en la actualidad.
2.3.3.1 Reutilizacin
Lo que entendemos por reutilizacin en este caso es la posibilidad de
estructurar un curso con (una o ms) piezas de otras fuentes, es decir,
contenidos de otros cursos que ya se hayan producido. Estas piezas suelen
llamarse como Objetos de Contenido Compartibles (Sharable Content
Objects, SCOs) u Objetos de Aprendizaje Compartibles (Sharable Learning
Objects, SLOs).
Las caractersticas necesarias para facilitar que un SCO sea reusable son
[DOD01]:
Independencia entre SCOs, para poder coger los que queramos sin
tener que llevar arrastrado al resto. Este punto no es sencillo, ya que
decidir a qu nivel un curso es independiente del resto de piezas
(nivel de leccin, de asignatura, de curso completo) puede llegar a
ser muy complicado [TELE01].
Calidad reconocida, de modo que podamos coger un SCO sabiendo

que es bueno sin necesidad de estudiarlo y evaluarlo, porque ya lo
han hecho otros. Un punto importante respecto a la calidad es que un
SCO pueda mejorar y por tanto tener distintas versiones.
Durabilidad, de forma que cuando hagamos un SCO podamos estar

seguros de que encajar en futuros cursos, aunque haya cambios
tecnolgicos.
34
Interoperabilidad, de forma que los contenidos puedan ser

operados por distintas plataformas de presentacin de contenidos,
por lo que hemos de separar el proceso de generacin de SCOs con
el proceso de uso de esos SCOs.
Permitir su uso por agentes. Como los SCOs se pretende que sean
muchos y se presenten de forma distribuida (en la web),
necesitaremos sistemas que nos permitan localizar los SCOs que ms
se adapten a nuestras necesidades, por lo que los agentes han de
entender las caractersticas de los SCOs. En este punto es donde
entra la web semntica y los lenguajes ontolgicos.
Como podemos comprobar, el desarrollo de una ontologa nos puede

facilitar las caractersticas arriba mencionadas. Una ontologa potencia la
independencia, ya que la ontologa estructurar los cursos y permitir una
fcil separacin lgica. Tambin permitir la interoperabilidad, ya que la
ontologa es independiente de la plataforma y puede servir de lenguaje
comn que permita conversiones entre unas plataformas y otras, as como
permitir el uso por parte de agentes. Las caractersticas de durabilidad y
calidad reconocida pueden facilitarse a su vez con fechas de creacin y
caducidad, as como por atributos que reconozcan a los autores de los
cursos.
2.3.4 Iniciativas de Teleeducacin

2.3.4.1 Tipos de iniciativas en Teleeducacin
En este apartado se clasificarn las distintas iniciativas. Dicha clasificacin
no es totalmente estanca, sino que puede que alguna iniciativa est ubicada
entre dos clasificaciones [MAK02] (ver Figura 2.2):
Especificaciones Tcnicas. Basndose en la Investigacin y

Desarrollo en eLearning y las necesidades de los usuarios, distintas
organizaciones generan especificaciones, denominadas libros
blancos, detallando un modelo de eLearning. Dicho modelo es
abstracto. Una de las organizaciones ms importantes que genera
especificaciones en eLearning es IMS Global Learning Consortium.
Estndares. Algunas especificaciones, cuando han sido

comprobados y acreditados, pasan a ser estndares. Si quien acredita
es un organismo, que para eLearning tenemos IEEE LTSC, ISO/EC-
JTC1/SC36 y CEN/ISSS, se denomina estndar de jure, y si lo que
35
les acredita es el mercado, al ser el ms aceptado por ste, se

denomina estndar de facto.
Modelos de Referencia. Son el resultado de concretar ms una

especificacin, de forma que se llega a implementar un modelo ms
completo (que puede basarse en Especificaciones Tcnicas y
Estndares, segn que partes del modelo, y adems recibe feed-back
de los que implementan soluciones comerciales, por si es necesario
concretar algn punto), incluso proveer una implementacin de
referencia y herramientas para comprobar si una implementacin
comercial cumple dico modelo de referencia. Como ejemplo
tenemos ADL-SCORM.
Implementaciones comerciales. Son el eslabn final de cadena y

representa los productos comerciales, que suelen seguir algn
modelo de referencia o al menos alguna especificacin, lo que se
puede entender como un cierto sello de calidad. No se sern objeto
de esta Tesis las implementaciones comerciales, ya las entidades que
realizan implementaciones comerciales suelen participar en la
definicin de los modelos de referencia y especificaciones tcnicas.
Como vemos en la figura 2.2 las distintas iniciativas se realimentan entre s,

de forma que puede que una parte de un modelo de referencia se base en un
estndar y luego lo mejore, modificando a su vez el estndar en el que se
basa. A su vez, una especificacin tcnica puede ser parte de un modelo de
referencia y a su vez un modelo de referencia modificar una especificacin
tcnica que el mercado acepta como mejora de la misma.
36
Mercado
I+D+I
Especificaciones
tcnicas
Modelos de
referencia
Estndares
Fig. 2.2. Relacin entre iniciativas de eLearning
A continuacin revisaremos las iniciativas de teleeducacin ms destacables

en la actualidad. Las ms destacables son las provenientes de las
especificaciones tcnicas de IMS, el modelo de ADL denominado SCORM,
y los estndares de IEEE LTSA, realimentndose entre s. En el
observatorio de LTSO [ANI04],[WWW69] podemos encontrar un
seguimiento actualizado sobre esta temtica.
A partir de la revisin de estas iniciativas se abstraern las partes ms

comunes y ms interesantes que puedan servir para la definicin de nuestra
ontologa, y se observarn las posibles carencias que pueda suplir la misma.
2.3.4.2 IMS
IMS Global Learning Consortium [WWW15], es un consorcio de empresas
e instituciones interesadas en la teleeducacin (sus miembros son
trabajadores de SUN, WebCT, MIT, Blackboard y varias Universidades).
37
Su funcin es publicar y actualizar especificaciones tcnicas, entendidas

como una serie de servicios que se utilizan para construir un sistema de
eLearning. Las especificaciones estn en continuo desarrollo, y suele
reutilizar a su vez estndares cuando una especificacin ha sido aprobada
como tal.
Las especificaciones de servicios [IMS03b] se distinguen entre los servicios

de la capa comn (Common Services Layer, CSL) y los de capa de
aplicacin (ASL). CSL son los servicios que no son especficamente de
eLearning, pero donde se apoyan stos, como el servicio de identificacin.
ASL son los especficos de eLearning (evaluaciones, calendario,
secuencialidad, gestin de contenidos,). Destaca sobre todo la
especificacin de evaluaciones (IMS QTI) [QTI06].
Respecto a sus especificaciones de estructuras de datos (Metadata

Specification) se basan en XML [IMS03a], y es en l donde se ha basado
IEEE-1484.1.2. (IEEE LOM), que veremos ms adelante. Adems, IMS
define sus entidades como Componentes, que se pueden entender como
parte de la ontologa implcita en IMS (Competencia, Contenido, Catlogo
de Cursos, Objetivo, objeto LOM,).
Respecto a su apoyo a sistemas colaborativos, incluye un mdulo

colaborativo que no est muy desarrollado. Respecto a la libertad del
alumno a elegir distintos caminos, soporta un servicio de secuenciacin
(Sequencing), que dice reglas para que el alumno pueda elegir entre varias
posibilidades.
Respecto a la bsqueda de contenidos, soporta un Discovery Service, para

buscar por toda la web, y en las primeras versiones habla del uso opcional
de UDDI (uno de los protocolos sustituidos por OWL-S).
IMS proporciona un Glosario [IMS03c], bastante interesante para estar

familiarizado con los acrnimos y entidades ms importantes en eLearning.
2.3.4.3 OKI
Open Knowledge Initiative (OKI) [WWW16] es una iniciativa del MIT que
define un conjunto de APIs en Java, a modo de modelo de referencia para
que se implementen dichas APIs. Hay algunos servicios que son iguales a
IMS, por lo que la API de OKI de esos servicios se puede considerar como
una implementacin de referencia del servicio.
38
2.3.4.4 IEEE LTSA

IEEE Learning Technology Systems Architecture (IEEE LTSA) es una
especificacin de una arquitectura de forma muy abstracta (ver Figura 2.3).
En dicha arquitectura hay unos Procesos (los que procesan informacin),

unos almacenes (de contenidos y seguimiento de alumnos), y unos flujos de
datos entre los dos grupos anteriores.
Esta especificacin de arquitectura se engloba dentro de IEEE 1484

Learning Technology Standards Committee (LTSC), que incluye estndares
destacables para los metadatos educativos [LTSC02], para la definicin de
tests y contestaciones de los mismos [IEEE05], y para la definicin del API
de comunicacin entre el usuario y el Learning Management System
[IEEE05].
Multimedia Learner Behavior
Interaction
Delivery context Evaluation
Learning
Locator parameters Assesment
Learning Learner
Context Info
Locator Catalog Coach
Info History
Query Learner
Learning Info Learner
Resources Records
Figura 2.3. Arquitectura IEEE LTSA
2.3.4.5 ADL-SCORM
Advanced Distributed Learning es un consorcio de entidades liderada por el
Departamento de Defensa de los Estados Unidos (DoD). A peticin del
DoD han creado un Modelo de Referencia denominado Sharable Content
Object Referente Model (SCORM).
39
SCORM pretende ser el modelo a seguir por la gran mayora de sistemas de

eLearning, ya que su mayor objetivo es la reutilizacin, y est apoyado por
el DoD. Se basa en modelos de referencia de IMS, Aviation Industry
Computer-Based-Training Committee (AICC), Alliance of Remote
Instructional Authoring & Distribution Networks for Europe [WWW21]
(ARIADNE, proyecto europeo financiado por el V programa marco) y en
Estndares de IEEE Learning Technology Standards Comit (IEEE LTSC).
SCORM se basa en una arquitectura que separa por completo la produccin

de contenidos (SCOs) y la distribucin de contenidos a los alumnos, que se
har a travs de un Learning Management System (LMS). Habla de
Experiencia de Aprendizaje (Learning Experience, LE) a lo que
entenderamos como un curso, ya que es un agregado de SCOs
empaquetado para ser utilizado.
El LMS debe poder trabajar con los contenidos de cualquier SCO que
cumpla el modelo de referencia:
Servir e inicializar SCOs a los clientes.
Permitir la navegacin a travs de los SCOs.
Tener funciones de comunidad web (foros, chats, etc.).
Seguir y guardar los datos de estado de un alumno en un momento

determinado.
Comunicarse con el SCO por medio de una API estndar.
Estas caractersticas son las que permiten que un SCO pueda interoperar
entre distintos LMSs, ya que todos los LMSs que cumplan con el modelo de
referencia, sabrn manipular e interactuar con el SCO.
Para realizar una divisin que permita trabajar slo con una parte del
modelo, el modelo SCORM se basa en tres submodelos:
Content Aggregation Model (Modelo de agregado de contenidos),

que describe qu es una LE y cmo empaquetarla, ponindole los
metadatos necesarios para que el LMS pueda explotarlo.
40
Run-Time Environment Model (Modelo de entorno de ejecucin),

que nos dice cmo se han de comunicar el LMS y el SCO mientras
el alumno est recibiendo la LE.
Sequencing and Navigation Model (Modelo de secuenciacin y

navegacin), que describe cmo puede moverse un alumno por el
curso (con ms o menos libertad) y define unos objetivos (goals) que
se pueden utilizar como reglas para decidir el camino que ha de
seguir el alumno. Est basado en el IMS Sequencing Model.
Como resumen vemos que el uso de las ontologas se hace a travs de los
meta-datos que describen el SCO, que se basa principalmente en IEEE LOM
1484.12.1
Como utiliza IMS para la secuenciacin, permite un cierto constructivismo.

A nivel de detalles en temas colaborativos, deja sin especificar el tema
pasndole toda la responsabilidad a quien implemente el LMS
correspondiente, sin generar un modelo de referencia al respecto.
De todas formas an se encuentra en proceso de desarrollo. La ltima

versin estable (SCORM 2004 2nd Edition) sali el 22 de Julio de 2004,
apareciendo ya en septiembre de 2004 una adenda con modificaciones.
Actualmente (Mayo 2006) se est trabajando sobre una tercera edicin de
SCORM 2004, que se encuentra an en estado de public draft
2.3.4.6 SIF
El Schools Interoperatibility Framework (SIF) es una especificacin para la
iniciativa K-12 (que pretende introducir el uso de nuevas tecnologas de la
informacin en la educacin en pases de habla inglesa), para promover la
interoperabilidad entre aplicaciones que cumplan la especificacin SIF.
Esta estructura pretende que cada aplicacin tenga al menos un agente, y

que los distintos agentes del sistema se comuniquen pasando por un punto
centralizado (con todas las consecuencias que tiene centralizar
comunicaciones), de forma que cada agente no tenga que conocer a todos
los dems.
2.3.4.7 OpenUSS
OpenUSS [WWW18] es un proyecto que ha desarrollado una especificacin
y est buscando realizar implementaciones de referencia. Dicha
especificacin se basa en Java 2 Enterprise Edition y tiene encima unos
41
componentes principales (Foundation Components) que se encargan de

representar asignaturas, alumnos, profesores, etc. y por encima de esta se
colocan los servicios horizontales a otros sistemas, como los chats,
contenidos para las clases, etc.
2.3.4.8 SUN Microsystems E-Learning Framework

Es una implementacin de referencia (define las APIs) y se basa en 4 capas:
Presentacin, que es la que lleva el contacto directo con el usuario.

Lleva la lgica de la navegacin y de la presentacin. Se basa en
portales.
Capa de servicios comunes, donde se incluyen tambin los servicios

de comunicaciones (e-mail, foros, web cast, white-boards y chats)
Capa de e-Learning, que lleva la parte de exmenes, simulaciones y

trabajo en grupo, entrega de contenidos, y herramientas de autor para
generar contenidos.
Capa de recursos, que tiene los repositorios de contenidos y los

meta-data para poder obtener esos contenidos. Permite el uso de
meta-datos de IMS y de Dubln Core Metadata. Tambin tiene
repositorios de evaluaciones y de informacin de los alumnos y otros
roles.
Esta separacin en capas se representa por medio de un conjunto de APIs

que se relacionan entre s y con la capa de presentacin por encima del
resto, siguiendo el paradigma modelo-vista. Adems dispone de una
implementacin de referencia que permite ver sus funcionalidades.
2.3.4.9 Otras Iniciativas

Existen otras iniciativas entre las que se puede destacar el EU UNIVERSAL
Project (proyecto financiado en el V programa marco), que buscaba
construir redes de bsqueda y entrega de materiales por medio de un broker
educacional. Se puede ofrecer contenidos y pedir contenidos, y se basa en
SOAP/WSDL y JXTA/EDUTELLA [WWW19].
El Gobierno del Reino Unido, dentro de su poltica de introduccin de

nuevas tecnologas en todos sus servicios, ha sacado UL Electronic
Governement Interoperatibility Framework (eGIF), que se basa en gran
medida en el modelo de IMS [WWW20].
42
2.3.5 Ontologas en Teleeducacin

Como ontologas en educacin nos referimos a las ontologas que se aplican
a los componentes de un curso on-line. Existen otras ontologas en
educacin como la de Knowledge On Demand (KOD), que utiliza una
ontologa en XML pero para describir las distintas reas de conocimiento
[SAM02].
Una vez enmarcado el mbito, encontramos tres ontologas destacables:

Dublin Core Group, ARIADNE, e IEEE LOM.
La primera es una de las ms antiguas y un esfuerzo centralizado de crear

unos metadatos globales. Dubln Core Group [WWW21] se cre en 1999 en
Ohio, y define una serie de conceptos globales como creator, date, que
siguen utilizndose en otros lenguajes (como en las anotaciones de OWL).
Se basa en 15 elementos principales: ttulo, creador, tema, descripcin,
publicador, colaborador, fecha, tipo, formato, identificador, fuente, idioma,
relacin, cobertura y derechos. Su sencillez y generalidad hace que se
reutilicen en otras muchas ontologas y lenguajes.
ARIADNE (Alliance of Remote Instructional Authoring and Distribution

Networks for Europe) es una asociacin internacional apoyada
institucionalmente por los programa Marco Europeos y su fin es fomentar el
intercambio de experiencias en el rea de la educacin abierta y a distancia.
Para realizar esto, centra su labor en la elaboracin de esquemas para los
metadatos educativos (llamado en este caso ARIADNE Metadata Set,
AMS), bastante parecido a la versin de IEEE que veremos a continuacin
(incluso existe una tabla de equivalencias entre ambos).
La ltima, ms aceptada como hemos visto en las iniciativas, es el IEEE

LTSC LOM (IEEE-LOM-1484.12) [WWW23]. Este modelo de objetos de
aprendizaje (Learning Object Model, LOM) divide la informacin en 9
subgrupos, y adems existe una especificacin para trascribirlo en ISO/IEC
11404 (IEEE-LOM-1484.12.2), XML (IEEE-LOM-1484.12.3) y RDF
(IEEE-LOM-1484.12.4) (Binding). El sistema es bastante completo (Se
bas en la recomendacin de IMS, que a su vez luego acepto IEEE LOM
como su base de definicin).
IEEE-LOM utiliza varias estructuras comunes para algunas de sus

propiedades:
43
Para la descripcin de roles, como los autores utiliza tripla de las

propiedades Role, Entity y Date. La propiedad Role indica el tipo de
rol, mientras que Entity identifica a la persona y Date la fecha de ese
rol.
Para la utilizacin de clasificaciones ya existentes, utiliza la pareja

de propiedades Catalog y Entry. La identificacin de la URI de la
clasificacin se encuentra en la propiedad Catalog, mientras que el
valor dentro de la clasificacin se introduce dentro de la propiedad
Entry.
44
Figura 2.4. Taxonoma de IEEE LOM
45
Como podemos ver en la figura 2.4, segn el modelo un objeto de

aprendizaje tiene las siguientes propiedades:
Los datos generales, ttulo, lenguaje, palabras clave, estructura y

nivel de granularidad. Este conjunto de datos nos permitira en su
caso bsquedas por texto, sobre todo para el ttulo y las palabras
clave.
Ciclo de vida, donde controla versiones, estado y autores. Esta

informacin nos permite distinguir entre distintas versiones, as
como poder solicitar la ltima versin que est en estado terminada y
revisada.
Meta-metadatos, son los datos a los metadatos que estamos

describiendo. En este punto se aaden tambin los autores de dichos
metadatos.
Datos Tcnicos de formato, tamao, requerimientos (y cmo

instalarlos), incluyendo informacin sobre la duracin. Los
requerimientos tcnicos pueden ser mltiples y adems poder elegir
entre varias posibilidades vlidas por medio de la propiedad
orcomposite.
Datos educacionales, tipo de interactividad, tipo de objeto de

aprendizaje (pregunta, una clase, una figura, etc), densidad
semntica (relacin entre el tamao y la cantidad de informacin
para el aprendizaje presentada), perfil del alumno, contexto,
dificultad.
Derechos de propiedad. Copyright, donde se describen los distintos

derechos de uso as como los precios relacionados para los mismos.
Este punto es uno de los menos desarrollados por IEEE LOM.
Datos de relaciones, habla de los Learning Objects con los que se

relaciona (usa metadatos de Dublin Core, ispartof, ). Este
apartado nos permitir que cuando exploremos un elemento
sepamos, y por tanto podamos explorar tambin, los objetos de
aprendizaje relacionados.
46
Anotaciones, son comentarios entre los creadores de contenidos.

Son campos bastante abiertos para anotaciones dirigidas a seres
humanos y no entendibles por los posibles agentes inteligentes.
Clasificacin, sobre qu temtica se habla, si es una disciplina, una

idea, una competencia,. Permite definir varias clasificaciones,
cada una con su propiedad Purpose que indica respecto a qu se
clasifica, como por ejemplo al tipo de pedagoga utilizado,
incluyendo tambin una informacin detallada dentro de la
propiedad TaxonPath, donde se indica un localizador a la
clasificacin particular en la propiedad Source y un valor dentro de
esa clasificacin en la subpropiedad Path- Entry (ver figura 2.4).
Como podemos apreciar, IEEE LOM cubre muchos aspectos de descripcin

de un objeto de aprendizaje, entendiendo el mismo como un contenido fijo
creado por algn autor o grupo de autores. Destaca su gran versatilidad al
permitir distintas clasificaciones con su tupla de propiedades Catalog y
Entry.
2.3.6 Estado del arte en las interacciones de tipo Foro

En este apartado veremos una de las interacciones usada no solamente en el
mbito de la formacin on-line, sino en otros mbitos de la web: los foros.
Este apartado aparece para demostrar con ms detalle el desarrollo de las
ontologas y clasificaciones en los foros, donde veremos la falta de
desarrollo y estandarizacin que actualmente existe.
Los foros son una herramienta que permite gestionar comentarios y

relacionarlos entre s, pudiendo visionar dichos comentarios desde la World
Wide Web. Se desarrollaron a partir de las listas de correo (mailing lists)
donde se empez a contestar a correos de la lista de forma que se generaba
un cierto hilo conversacional.
Normalmente un foro es uno o varios hilos (threads o topics) sobre los que
los usuarios realizan comentarios o contestan a comentarios de otros
usuarios. En los siguientes apartados veremos las funcionalidades que
suelen llevar aparejadas.
Los foros son una herramienta de interaccin que se sita entre la

correspondencia de e-mail y las conversaciones sncronas por medio de
chats. Permite el almacenamiento de la historia de la conversacin, as como
la existencia de ciertos moderadores de los foros.
47
Los distinguimos de los blogs (weblogs) ya que normalmente los blogs son
un conjunto de artculos alrededor de una temtica que mandan usuarios y
que son comentados (por un sistema similar al foro) posteriormente por
otros usuarios y el autor. Aunque algunos foros permiten que se te enve por
e-mail las interacciones de otros usuarios, se distingue de las listas de correo
porque la accin ms comn es la visita del foro ms que la espera pasiva a
recibir mensajes. De hecho, debido a que el tiempo para leer e-mails es
limitado, las listas de e-mail se vuelven inapropiadas en temticas en las que
se reciben gran nmero de interacciones.
Fig. 2.5. Ejemplos de estructuras visuales de rboles con threads
El nacimiento de los foros como los conocemos actualmente se da en 1996

con Ultimate Bulletin Board [WWW41], con el nacimiento de la estructura
visual de rbol con threads (ver Fig. 2.5) (de hecho, muchos foros an son
considerados an como Bulletin Board Systems o BBS). An as hubo otras
herramientas de conversacin como los newsgroups y de intercambio de
informacin como los BBSs (que funcionaban por modem antes de
Internet), pero consideraremos los foros como los foros que actualmente se
muestran por la web.
Hoy en da la mayora de plataformas de teleformacin ofrecen herramientas

de tipo foro, aunque la utilizacin de foros sobrepasa el mbito del
48
aprendizaje y podemos encontrar aplicaciones dedicadas exclusivamente a

la gestin de foros, desde aplicaciones Open Source como phpBB
[WWW42] (basada en php y preferentemente base de datos MySQL) hasta
aplicaciones de pago como BlaBla4U [WWW42] (basado en .asp y
Microsoft SQLServer) o FuseTalk [WWW43] (programado en ColdFusion
y con una versin para ASP.NET). Podemos encontrar en [WWW44] una
interesante comparativa sobre aplicaciones de foros con fecha de noviembre
de 2005.
2.3.6.1 Motivacin de los Foros

Los foros nos permiten interactuar por medio de comentarios enlazados con
los distintos grupos de inters de la comunidad (alumnos y profesores en un
curso, miembros en un foro temtico, etc). Estas interacciones nos permiten:
Generar una base de conocimiento, ya que los distintos comentarios

y conversaciones quedan almacenados en el sistema, pudiendo
buscar en el mismo en la mayora de los casos. Es el caso de la
comunidad de desarrolladores en Java de Sun (JavaDeveloper)
[WWW46], donde se pueden realizar bsquedas por los distintos
foros. Muchas veces se genera una base de conocimientos ms
elaborada, donde se revisan las cuestiones ms importantes
planteadas y resueltas en los foros y se incluyen a modo de
preguntas frecuentes (faqs).
Fomentar la comunicacin entre el individuo y el grupo, generando

un sentimiento de pertenencia y reconocimiento. Por ejemplo, los
alumnos de los cursos on-line pueden contactar y hacer preguntas a
la comunidad de aprendizaje que consideran interesantes para los
dems, incluso contestar a preguntas de otros alumnos, realizando un
cierto reconocimiento dentro del grupo. Esto hace que se faciliten la
segunda y tercera interaccin bsica segn Moore [MOO89]:
aprendiz-experto (tutor) y aprendiz-aprendiz.
Para los cursos on-line los foros permiten al tutor aadir informacin
extra o actualizaciones cuando el curso ya ha arrancado. Por
ejemplo, el cambio de una ley a mitad de un curso sobre fiscalidad
puede ser comentado por el tutor cuando algunos alumnos ya hayan
pasado la unidad que ha quedado obsoleta.
Sirven para sondear a la comunidad, sea de un curso on-line o no.

Por ejemplo si una unidad no est clara aparecern comentarios al
49
respecto en el foro, o si algunos alumnos no estn satisfechos

probablemente lo indiquen en el mismo. Esto puede servir durante la
imparticin del curso para ir modificando alguna de las acciones o
poniendo ms cuidado en la tutorizacin si es necesario.
Puede generar una comunidad de aprendizaje a su alrededor. Por

ejemplo, un foro sobre programacin de php puede concentrar tanto
expertos como novicios en la temtica de forma que pueden
interactuar de forma algo ms informal y permitir un tipo de
formacin muy dirigida, incluso produciendo conocimiento como se
indica en la teora de la espiral de Nonaka [NON95] (Ver figura 2.6),
donde se va generando conocimiento pasando entre conocimientos
tcitos (los que no se han expresado formalmente) y explcitos de
forma matricial. En este caso corresponde a un proceso de
socializacin-externalizacin. De hecho, en algunos casos los
propios usuarios de un curso on-line solicitan el mantenimiento del
foro durante mucho ms tiempo que el curso.
A:
TACITO EXPLICITO
TACITO
SOCIALIZACION EXTERNALIZACION
DE:
EXPLICITO
INTERNALIZACION COMBINACIN
Fig. 2.6. Espiral de Nonaka
50
2.3.6.2 Limitaciones de los Foros

Las propias caractersticas de los foros acarrean ciertas limitaciones en
algunos casos:
Introduccin en el foro de comentarios poco interesantes o no

relacionados con el rea de inters del mismo. Esto genera cierta
informacin no til en el foro que dificulta la informacin
interesante. Un caso tpico son los spams realizados a foros
(comentarios publicitarios no relacionados con la temtica colocados
por personas o agentes de spam que escanean la web en busca de
foros). Otro caso tpico es utilizar el foro para comunicaciones entre
usuarios que no son interesantes para la comunidad en s, sino slo
para los dos individuos que siguen la conversacin.
Para evitar esta informacin no til se suele recurrir a la figura del

moderador del foro (que pude decidir qu introducir y qu no en el
foro, o borrar comentarios, o indicar a usuarios que sigan su
comunicacin en privado por medio de chat o e-mail).
Introduccin en el foro de contenidos ofensivos u opiniones a modo

de calumnias. Estos comentarios se suelen realizar al amparo del
anonimato de algunos foros y genera la falsa impresin que todo el
foro comparte esas ideas o calumnias. Algunos de estos casos son
investigados judicialmente como es el caso de e-valencia.org en
mayo de 2005.
Estos comentarios se suelen evitar con el uso de un moderador y no

permitiendo el completo anonimato en los foros. De todas formas
hoy en da se realiza el seguimiento judicial en Espaa ya que la
LSSI [LSSI02] obliga a los sistemas a almacenar las IPs y fechas de
conexin al sistema durante al menos un ao.
Este punto y el anterior en principio se basan en el seguimiento de

[RFC1855], conocida tambin como nettiquete y que regula el buen
comportamiento en las comunicaciones uno a uno y uno a un grupo.
Tiempos entre comentarios y contestaciones. Al ser un tipo de

conversacin asncrona, la contestacin a un comentario
normalmente no es instantnea. En estos casos el posible actor que
replique ha de entrar en el foro, mirar el comentario y estar
51
interesado en contestar a la misma. Luego el sujeto interesado ha de

acceder de nuevo a leer la respuesta.
Para acortar estos tiempos, algunos foros envan avisos por medio de
e-mails a los usuarios cuando se contesta a un comentario suyo o
cuando se realiza una interaccin en un thread o comentario en el
que nos hemos registrado como interesados. Los usuarios de los
foros han de acostumbrarse tambin a realizar comentarios que sean
interesantes para el grupo para obtener respuestas.
Dificultades para fomentar la participacin. Sobre todo en las

comunidades sobre cursos on-line, a veces es difcil arrancar
conversaciones hiladas entre los alumnos, que se limitan a leer los
comentarios ya existentes (lurking), leer los contenidos del curso y
aprobar el examen en su caso. De hecho hay cursos en los que las
nicas interacciones en los foros son de los tutores para informar a la
comunidad sobre algn tema.
Para evitar la pasividad en los foros los tutores han de animar a los
alumnos a participar, o incluso recurrir a otra figura como el
facilitador que realiza estas tareas de animacin y seguimiento
general [MON02].
2.3.6.3 Caracterizacin de los foros

En este caso veremos dos clasificaciones de los foros: segn las
caractersticas que implemente y segn las interacciones que contenga.
Segn caractersticas implementadas tenemos:
Foros con / sin moderador. Debido al esfuerzo que significa

moderar todo un foro, en algunos casos puede haber un moderador
centralizado o con posibilidad de poder delegar la moderacin para
algunas partes del mismo.
Foros independientes / embebidos con otros recursos. Los foros

relacionados con otros recursos suelen ser por ejemplo los
relacionados con un curso on-line, o incluso podemos considerar que
algunos blogs tienen un foro relacionado con los artculos
publicados. Los blogs, por s mismos tambin pueden dar lugar a
conversaciones (artculos que comentan otros artculos) entre blogs
distintos (un blog A comenta el texto de un blog B), siguiendo la
52
especificacin TrackBack [TRO04]. Comentaremos esta

especificacin ms adelante.
Generales / Personalizados para los usuarios. La personalizacin

puede indicarte los comentarios an no ledos, avisarnos por e-mail
cuando haya contestaciones a nuestros comentarios o incluso
recordar mis preferencias de navegacin y lay-outs.
Grandes y generales / pequeos y enfocados a una temtica.

Normalmente los grandes y generales pretenden una socializacin
ms all de una disciplina determinada (como ocurre en Japn con
2Channel [WWW48]). En Europa y Estados Unidos se extienden
ms los pequeos y enfocados como pueden ser foros de
programacin en php [WWW47].
Slo textuales / foros que permiten ms tipos de recursos, como

imgenes, links, archivos adjuntos. Los textuales normalmente son
ms ligeros y permiten un mayor nmero de interacciones, mientras
que los otros permiten una mejor expresin de los comentarios.
Por otro lado, basndonos en las interacciones que contiene [DRI04],

podemos realizar la siguiente clasificacin:
Nivel de interaccin de los foros: midiendo cantidad y frecuencia

de nuevos comentarios y respuestas a los mismos (dos indicadores
separados). Esta caracterstica se puede dividir por perfiles en los
cursos on-line (tutores, facilitadores, aprendices).
Nivel de Centrado en la temtica del foro: midiendo los mensajes

relacionados con la temtica frente al total de mensajes.
Tiempo medio de respuestas: midiendo horas/das entre que se

realiza un comentario que necesita respuesta y la respuesta si
aparece.
Dedicacin media a revisar otros comentarios: tiempo medio de

los usuarios (en caso de ser identificado) visitando el foro y no
interactuando en el mismo. Se pude medir tambin por medio de
medir la media de comentarios visitados por cada usuario.
53
En los cursos on-line se puede medir las relacin entre

interacciones alumno-alumno, alumno-tutor y tutor-alumno.
Sobre todo es importante la interaccin entre alumnos, que indica la
creacin de una comunidad de aprendizaje.
2.3.6.4 Metadatos y Ontologas en los Foros

Una vez descritos los foros as como los distintos tipos y caractersticas de
los mismos, pasamos a enumerar los trabajos relativos a la generacin de
ontologas y metadatos de los foros. As como para los contenidos estticos
y los cuestionarios hay gran cantidad de propuestas para la
interoperabilidad, no encontramos apenas ninguna informacin de los foros,
debido a dos causas:
1. Se prioriza la interoperabilidad en el siguiente orden:
a) de los contenidos estticos del curso (pginas html, algn

recurso en javascript, imgenes, videos, etc), como ocurre
en SCORM Content Agregation Model (CAM)
[ADL04a].
b) de la estructura del curso y navegacin (unidades y forma

de navegar), como ocurre en SCORM S&N [ADL04c].
c) de la interaccin del alumno con los contenidos (pruebas

y exmenes). En este caso SCORM lo recoge en su libro
sobre Run Time Environment [ADL04b].
Como no se han resuelto an los puntos anteriormente citados, la

interoperabilidad de los resultados de interacciones entre los
miembros de la comunidad de aprendizaje (como los foros) no se
han estudiado an. De hecho, por ejemplo el referente actual
SCORM indica que no soporta ningn tipo de informacin relativa a
las interacciones colaborativas de los cursos [ADL04c] ni a nada que
no sea el aprendizaje individualizado alumno-sistema [REB04].
2. Se considera poco til la exportacin (interoperabilidad) de las

interacciones de un curso, por no haber encontrado an
beneficios que lo justifiquen.
Lo nico que se ha encontrado que puede ser considerado como

posible exportacin de foros, es la exportacin de los diferentes skins
54
(apariencias, traducciones a otros idiomas) de los foros as como la

particularizacin de foros generales (por ejemplo, un foro en el que
slo puede abrir threads el administrador)[MODX06]. Esto permite
que un sistema que est ya particularizado por medio de un archivo
XML que describe las modificaciones (MODX) se pueda actualizar
con nuevas versiones del software de foros y al aplicar de nuevo el
MODX quede de nuevo particularizado (ver Fig. 2.7).
SISTEMA DE FOROS ESTANDARD
Archivo xml que indica los cambios

MODX1 a hacer en los ejecutables para
personalizar el foro
SISTEMA DE FOROS PERSONALIADO
Fig. 2.7. Ejemplo de funcionamiento del MODX de BBphp
Pese a no existir ms implementaciones, consideramos que la exportacin

de metainformacin de los foros y de los foros en s puede generar mltiples
beneficios:
Como hemos comentado anteriormente, un foro bien gestionado

genera una base de conocimiento que podramos aprovechar en otras
imparticiones del mismo. De hecho, una forma rudimentaria de
hacerlo es generar un apartado de preguntas frecuentes a partir del
foro.
El mantener un foro para sucesivas ediciones del curso nos puede

servir para enriquecer al mismo. Eliminar directamente un foro de un
curso es como si perdiera la memoria y experiencia obtenida por
medio de someterse a una imparticin del mismo.
Nos permitira ampliar las bsquedas, ya que no slo buscaramos

por los contenidos de los cursos, sino por los topics de los foros (la
55
temtica si la marcamos) o incluso por los contenidos textuales de

los mismos foros.
Por ejemplo, si queremos buscar la solucin a un problema concreto,

es ms fcil que lo encontremos en un foro que encontrarlo
explcitamente en los contenidos estticos de un curso. Mientras en
los contenidos de un curso aparece informacin estructurada sobre
un rea de conocimiento, en los foros aparece informacin
completamente desestructurada pero muy orientada a los intereses de
los miembros de la comunidad.
2.3.7 TrackBack
El ejemplo ms similar a una ontologa para los foros ha sido el sistema de
enlace entre blogs distintos implementado por TrackBack. Trackback
apareci como primera versin en 2002 y permite enlazar artculos de
distintos blogs a modo de conversaciones (como si fuera un foro
distribuido).
TrackBack nos permite avisar a un Blog A de que alguno de sus artculo se

comenta en un artculo del Blog B. Si bien la mayora de los blogs permiten
aadir comentarios a un artculo directamente, esto puede que no sea la
solucin ms adecuada porque:
a) produce una centralizacin de la informacin. A veces hay blogs

que no estn interesados en almacenar comentarios de otros
usuarios ajenos al blog.
b) resta importancia al segundo artculo, ya que queda como un

simple comentario al primero y no como una contribucin del
segundo autor (en su blog). Adems, hace que el segundo
artculo est condenado a desaparecer si el primer blog
desaparece.
c) permite comentar de forma estndar artculos de otros blogs.

Esto nos permite comentar los mejores artculos, que
normalmente se encuentran distribuidos en distintos blogs
Trackback se puede considerar como una forma de averiguar quin

referencia nuestros recursos (linkback), y as poder ver ms informacin
relacionada con los mismos.
56
2.3.7.1 Funcionamiento de Trackback

Trackback funciona basndose en la arquitectura Representational State
Transfer REST [FIE00]. Se basa en HTTP y XML, de forma que el cliente
manda al servidor una peticin por POST y el servidor le contesta con un
archivo XML.
En el caso de Trackback el funcionamiento es el siguiente:
1. Un usuario genera un artculo (artculo B) comentando un

artculo de otro blog (artculo A).
2. El usuario localiza una URL permanente del artculo (permanent

link) del artculo al que referencia. Indica a su sistema que quiere
referenciar ese artculo.
3. Se realiza un mecanismo automtico de descubrimiento de la

URL de Trackback del artculo A (trackback ping URL).
4. El blog del artculo B acta como cliente y manda un HTTP

POST a la Trackback ping URL indicando cierta
metainformacin sobre el artculo B.
5. El cliente HTTP contesta por medio de un archivo XML donde

indica si todo ha sido correcto o si ha habido algn error.
La forma de averiguar la trackback ping URL a partir de la URL

permanente se hace por medio de informacin en RDF insertada en la URL
permanente, donde indica metainformacin sobre el artculo A entra la que
se encuentra su ping URL.
Pingback [LAN02] funciona de forma similar, slo que utilizando XML-

RPC y que coloca dentro de la pgina del blog A una marca <link
rel="pingback" href="ServidorPingBack"> (o una propiedad en la cabecera
del HTTPResponse).
Podemos ver el funcionamiento en la figura 2.8.
57
CLIENTE BLOG-B SERVIDOR - BLOG A
HTTP-GET URL PERMANENTE
URL PERMANENTE - RDF EMBEBIDO

OBTENCIN DE TRACKBACK PING URL
DEL RDF
HTTP POST + DATOS ARTICULO B
XML RESPONSE (OK O ERROR)
Fig. 2.8 funcionamiento de trackback
2.3.7.2 Metainformacin en Trackback

Trackback encapsula la metainformacin de los artculos de dos formas
distintas:
Para el artculo de origen (el que se referencia) en el propio artculo

se incrusta una descripcin en RDF utilizando campos de Dublin
Core. En el ejemplo 2.7 podemos ver un ejemplo de RDF incrustado.
58
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
rdf:about="http://www.w3.org/QA/2005/08/variability_in_specifications.html"
trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/7"
dc:title="Variability in Specifications published as a W3C Working Group
Note"
dc:identifier="http://www.w3.org/QA/2005/08/variability_in_specifications.ht
ml"
dc:subject="Publications"
dc:description="Variability in Specifications, a companion to the QA
Framework: Specification Guidelines, has been updated and published as a W3C
Working Group Note. The Note contains advanced specification design
considerations and conformance-related techniques. It describes how design
of a specification's conformance..."
dc:creator="karl"
dc:date="2005-08-30T00:46:17+00:00" />
</rdf:RDF>
Ej. 2.7. RDF en
http://www.w3.org/QA/2005/08/variability_in_specifications.html
Para enviarla al servidor en el HTTP-POST. En este caso no se

utiliza ningn formato ms que el del propio POST, indicando los
siguientes campos:
a) Ttulo (title) del artculo B.
b) Resumen (excerpt) del artculo B. Normalmente el resumen lo

especifica el autor o se coge una cantidad de texto del principio
del artculo (como en las sindicaciones RSS y ATOM).
c) URL permanente del artculo B (url). Es el nico campo que es

obligatorio. En cierto modo indica al padre (Trackback ping
URL con la que conecta) el nombre de un artculo hijo suyo
(referencia al anterior).
d) nombre del blog donde est el artculo B (blog_name).
Como podemos ver la metainformacin de trackback es muy limitada y no

sigue estndar de web semntica (RDF) en la descripcin de una fuente a
referenciar, cuando se enva la informacin del artculo B que referencia al
anterior se realiza una comunicacin HTTP POST.
59
TrackBack de todas formas sirve para lo que fue diseado (informar a un

artculo que otro articulo le referencia). Por tanto, hasta donde alcanza
nuestro conocimiento, no existe ninguna ontologa que trabaje con los foros
de forma explcita, lo que confirma que realizar la prueba de concepto con la
subontologa que generemos de foros ser un trabajo nico dentro del
campo en el que estamos trabajando.
60
Captulo 3. Lgica y Web Semntica
Captulo 3: Lgica y Web

Semntica
3.1 Introduccin
En este captulo introducimos los conceptos y explicaciones principales
respecto a las teoras de lgica y raciocinio, lo que nos permitir:
Conocer las teoras que dan lugar a la lgica descriptiva que se

utiliza como base para el lenguaje ontolgico elegido (OWL DL).
Entender la potencia y las limitaciones de los lenguajes ontolgicos,

as como los algoritmos de razonamiento en los que se basan los
razonadores actuales.
Enmarcar el lenguaje OWL DL dentro de los lenguajes lgicos

existentes en la actualidad para la Web.
61
Conocer los detalles sintcticos y semnticos de los principales

lenguajes lgicos, y en particular los de la familia OWL (Lite, DL y
Full).
Es decir, en este captulo asentaremos las bases que nos permitirn entender
OWL DL y enmarcarlo dentro de las distintas lgicas existentes, donde
podremos ver que es una de las lgicas ms ricas semnticamente y adems
que permiten razonamientos en la misma con tiempos de procesamiento
finito y razonable.
3.2 Lgica y razonamiento

3.2.1 Introduccin
En este apartado describiremos los diferentes tipos de lgica, as como las
caractersticas de cada una y las posibilidades de razonamiento. Aunque no
es objetivo de esta Tesis profundizar en estos temas ni en desarrollar nuevos
algoritmos para optimizar las inferencias, s que es necesario conocer al
menos los nombres y las implicaciones que actualmente conlleva utilizar
una lgica u otra a la hora de describir nuestras ontologas.
Los sistemas de web semntica actuales se basan en una Base de

Conocimiento (Knowledge Base, KB), y algn Motor de Inferencia
(Inference Engine, IE):
La Base de Conocimiento ser un conjunto de sentencias, que

pueden ir creciendo y variando en el tiempo, en un lenguaje formal,
de forma que los agentes inteligentes reunirn las sentencias de otros
servicios en la web, y construirn su base de conocimiento sobre la
que trabajar. En la mayora de los casos los agentes inteligentes son
programados con programacin declarativa, en la que el agente
obtiene la informacin que necesita saber y se le plantea que
resuelva un problema, sin indicarle el algoritmo determinado para
resolver ese problema.
El Motor de Inferencia ser lo que permitir al agente sacar

conclusiones de la base de conocimiento y resolver el problema que
se le ha planteado. El motor de inferencia permitir obtener nuevas
sentencias (conclusiones) a partir de las sentencias de su base de
conocimiento, y determinar, por ejemplo, si una sentencia es
deducible a partir de las sentencias de su base de conocimiento.
62
Tambin permite determinar si una determinada sentencia es

imposible a partir de su base de conocimiento, es decir, nos lleva a
una contradiccin. Otro posible resultado es concluir que una
sentencia no es imposible, pero no es deducible de nuestra base de
conocimiento.
Recordemos que un lenguaje lgico es un lenguaje formal para representar

informacin de la que se puedan sacar conclusiones, y dispone de una
sintaxis (las sentencias vlidas en el lenguaje) y una semntica (qu
significan esas sentencias).
3.2.2 Tipos de lgica
Lenguaje Qu hay en mi Qu puedo saber respecto a algo

abstraccin del mundo
L. Proposicional Hechos Verdadero/falso/desconocido
L. Primer Orden Hechos, objetos, Verdadero/falso/desconocido
relaciones
L. Temporal Hechos, objetos, Verdadero/falso/desconocido
relaciones, tiempos
L. Probabilstica Hechos Grado de certeza [0,1]
L. Difusa Grado de verdad Grado de certeza [0,1]
Tabla 3.1. Tipos de lgica
Las lgicas nos sirven para abstraer el mundo real y quedarnos slo con
nuestra rea de estudio, utilizando unos operadores dependientes de cada
lgica que nos permiten obtener conclusiones.
Podemos clasificarlas en funcin de dos parmetros, como podemos

observar en la tabla 3.1:
Segn los distintos elementos de mi abstraccin del mundo real

sobre los que podemos concluir algo. El ms sencillo es cuando slo
podemos sacar conclusiones de hechos. Por ejemplo, un hecho es
que Pedro es padre de Luis, donde no podremos nunca separar
Pedro de Luis o de ser padre de. La dificultad aumenta cuando
podemos dividir los hechos en sujetos, predicados (objetos) y
relaciones entre los mismos. De esta forma los hechos los podemos
dividir en triplas de elementos diferenciados, como
<Pedro,serPadreDe,Luis> en el ejemplo anterior Podemos ir
63
aumentando la cantidad de elementos distintos aadiendo, por

ejemplo, tiempos. En este caso se aade una variable temporal o de
periodo temporal a la tripla, pudiendo realizar sentencias como Juan
vivi en Paris del 2004 al 2006, quedando los elementos
diferenciados <Juan,vivirEn,Paris,2004 al 2006>. La lgica
probabilstica habla de hechos, que pueden ser verdad o mentira con
un grado de probabilidad (Juan mide 1.83 m, que puede ser vedad o
mentira). La lgica Difusa trata del grado de verdad, ya que se
trabaja con percepciones difusas en lugar de datos exactos (por
ejemplo, puedo decir que Juan es alto, pero el trmino de alto
depende de qu interlocutor lo afirme).
Segn las conclusiones que se pueden obtener respecto a los

elementos de la abstraccin del mundo. Tenemos dos grupos
diferenciados, siendo uno de ellos el grupo en el que un elemento es
cierto, falta o desconocido (aunque seguro que slo puede tener el
valor de cierto o de falso). El segundo grupo introduce una
gradacin en la certeza, de forma que un elemento tiene valor
graduado de probabilidad de que sea cierto (o ocurra) o no, que vara
del 0 como falso al 1 como completamente cierto. Este segundo
grupo es ms complicado de tratar. As, por ejemplo, en el primer
grupo puedo llegar a conclusiones del tiposi Juan es mi padre y
Pedro si hermano, entonces Pedro es mi to, en la que ha de darse
las dos premisas como ciertas para poder llegar a la conclusin. Sin
embargo, en el segundo grupo podemos realizar aserciones como si
hay una probabilidad de que Juan sea mi padre del 80% y una
probabilidad de que Pedro sea su hermano del 70%, entonces la
probabilidad de que Pedro sea mi to es del 56%.
Si en nuestra abstraccin de la realidad pueden existir slo hechos, y si

adems podemos decir que los hechos son ciertos, falsos, o desconocidos,
entonces estamos tratando con Lgica Proposicional. Si lo que indicamos
sobre los hechos es que pueden ser ciertos segn una graduacin, trabajamos
con lgica probabilstica.
Si el mundo abstrado tiene ms cosas que hechos, tiene objetos y relaciones

entre ellos, podemos estar utilizando Lgica de Primer orden. Si adems se
utilizan parmetros temporales nos referimos a Lgica Temporal.
Normalmente las lgicas con ms variables suelen llamarse lgicas de orden
superior.
64
Existen otros tipos de lgica, como podemos ver en la tabla 3.1, pero slo
profundizaremos en la Lgica Proposicional, en la Lgica de Primer Orden
(FOL), y dentro de FOL profundizaremos un subconjunto de sta, la Lgica
Descriptiva (Description Logics, DL). Empezaremos con la lgica
proposicional, ya que es la base de las otras lgicas, y en particular de la
lgica de primer orden. Puesto que la web semntica se basa en la lgica de
primer orden, la desarrollaremos con detalle, y en particular un subconjunto
de la misma, la lgica DL. La razn por la que trabajaremos con lgica DL
radica en que, como veremos, es un subconjunto de FOL que permite
implementar razonadores que realizan inferencias en tiempos razonables, y
por eso es el subconjunto ms utilizado dentro de la web semntica.
3.2.3 Razonamiento
Se define modelo [FRA01] como un mundo estructurado con respecto al
cual podemos evaluar la veracidad o no de algn hecho. Por ejemplo,
cuando en lgica proposicional tenemos dos hechos Me levanto pronto los
lunes y llego pronto al trabajo los lunes, un modelo posible es que sea
cierto que me levante pronto los lunes, y falso que llegue pronto al trabajo
los lunes. En principio hay tantos modelos como posibilidades de un sistema
sin llegar a contradicciones.
Se habla de que una base de conocimiento KB, supone la frase (o funcin

lgica, como combinacin de frases)
KB [Expr. 3.1]
Si es verdad en todos los modelos (mundos posibles) de KB.
KB sii M(KB) M() [Expr. 3.2]
Siendo M(KB) el conjunto de todos los modelos de KB y M() el conjunto

de todos los modelos en los que puede ser cierto. Esto nos indicar que la
frase es derivable de nuestra base de conocimiento, ya que no es posible
un modelo de KB que no sea modelo de .
Se dice que la frase (o funcin lgica) se puede derivar (deducir o inferir)

de la base KB por medio del procedimiento p
KBp [Expr. 3.3]
Dicho procedimiento puede ser:

65
1. Seguro (con sentido) si siguiendo ese procedimiento p, llegamos a

una conclusin , dicha conclusin es una suposicin de nuestra KB,
es decir, que el procedimiento nos da slo conclusiones que son
correctas.
Siempre que KBp , es cierto que KB [Expr. 3.4]
2. Completo, cuando si algo se puede concluir de una KB, se puede

inferir por medio del procedimiento p. Es decir, si algo es correcto,
podremos sacarlo por medio de p.
Siempre que KB , sabemos que KBp [Expr. 3.5]
Nos interesarn siempre procedimientos que den conclusiones correctas y

adems que puedan obtener siempre una conclusin si es correcta (seguros y
completos).
La lgica proposicional tiene procedimientos seguros y completos, sin

embargo hay otras lgicas mucho ms expresivas (permiten mundos ms
complejos y por tanto ms cercanos a la realidad) que tambin los tienen,
como por ejemplo la lgica de primer orden (FOL) [FRA01] [ARE01].
Sin embargo, otra caracterstica que nos interesar es que dichos

procedimientos sean eficientes computacionalmente hablando, por lo que
nos veremos obligados a restringir FOL en forma de Lgica Descriptiva
(Description Logics. DL) como veremos ms adelante. Por esto mismo, a
veces nos tendremos que conformar con procedimientos que sean seguros,
pero no completos.
3.2.4 Lgica Proposicional LP

La lgica proposicional es el sistema lgico ms simple de los que veremos
en esta Tesis, y se basa en proposiciones atmicas, de las que slo podemos
indicar si son verdaderas o falsas, y que pueden constituir proposiciones
ms complejas asocindose con conectores y, o, si entonces o ...es
equivalente a.... Su sintaxis y semntica, que veremos a continuacin,
definen con ms detalle esta lgica.
3.2.4.1 Sintaxis en LP
La lgica proposicional basa su sintaxis en un conjunto de proposiciones
atmicas = {A,B,C} indivisibles e independientes entre s, que se
66
podrn combinar entre s a modo de frmulas lgicas. Podemos ver en la

Tabla 3.2 un resumen de las mismas.
Smbolo Denominacin
T Verdadero
F Falso
A Negacin
A B Conjuncin
A B Disyuncin
AB Implicacin
AB Equivalencia
Tabla 3.2. Resumen de la sintaxis
3.2.4.2 Semntica en LP
En esta lgica, llamaremos Interpretacin I sobre un conjunto de tomos
a una funcin que nos dar un valor verdadero o falso por cada proposicin
atmica.
I: {T,F} [Expr. 3.6]
La interpretacin de x la representaremos de la siguiente forma:
I (x) o tambin xI [Expr. 3.7]
Esto nos permitir pasar a la semntica de esta lgica (Tabla 3.3). Dicha
semntica es aplicable tambin a combinaciones de proposiciones atmicas.
Sntaxis Significado Explicacin

I el tomo A es cierto en la
IA A
interpretacin I
I A A no se satisface (es A es falso en la
falso) en I interpretacin I
I A B IA y adems IB A y B son ciertos en la
interpretacin I
I A B IA o (no exclusiva) Al menos uno de los dos, A o
B es cierto en la
IB
interpretacin I
I A B Si IA, entonces IB No es posible que B sea
67
cierto en I y no lo sea A
I A B IA, si y slo si IB A y B son los dos verdaderos
(A B en esa o los dos falsos a la vez en I
interpretacin)
I T Verdadero es verdad
en cualquier
interpretacin I
Falso no es verdad (no
I F se da) en cualquier
interpretacin I
Tabla 3.3. Semntica
Adems, existe una relacin entre los distintos operadores, de forma que
pueden transformarse entre s. Las ms importantes se ven en la tabla 3.4.
Frmula Equivalente
A B ( A B )
( A B ) (A B )
( A B ) (A B )
A ( A B) A
A ( A B) A
,, son conmutativas y asociativas
es distributiva frente a
es distributiva frente a
Tabla 3.4. Equivalencias
3.2.4.3 Formulacin en LP
Se dice que una frmula lgica es [FRA01]:
Posible, si hay alguna interpretacin I que la satisface (hace que sea
cierta).
Imposible, si no hay ninguna interpretacin que la haga cierta, es

decir, que en ninguno de los posibles mundos puede darse.
Vlida o tautologa si con cualquier interpretacin I hace que la

frmula sea cierta.
68
Invalidable si hay al menos una interpretacin que hace que la

frmula no sea cierta.
En nuestro campo de trabajo una frmula ser el conjunto de nuestra base de

conocimiento, al que aadiremos algunas subfrmula o frases nuevas para
comprobar si se deducen de nuestra base de datos, o se contradicen, o slo
son posibles o invalidables.
Los sistemas actuales que tratan con gran nmero de variables se basan
normalmente en demostrar que una frmula es posible (buscar una
implementacin que se cumpla, y no hace falta seguir) o recorrerlas todas y
ver que ninguna es posible. Se puede convertir cualquier otra formulacin
en LP en una formulacin de posibilidad De hecho una frmula x es una
tautologa si la frmula x es imposible (cuando no se encuentra ninguna
interpretacin que lo cumpla, tras pasar por todas), y una frmula x es
imposible si x es una tautologa. Una frmula x es Invalidable si x es
posible.
Adems, las frmulas se suelen transformar para normalizarlas, de modo

puedan ser tratadas con algn algoritmo que necesita esa normalizacin.
Como formas normales tenemos:
Conjunctive Normal Form CNF, que consiste en dejar todo como

proposiciones atmicas (negadas o no) enlazadas entre s por
disyunciones (subfrmulas) y stas a su vez enlazadas por
conjunciones.
(
in=1 mj=1 Ai , j ) [Expr. 3.8]
De este modo, si todas las subfrmulas contienen T o proposiciones

atmicas complementarias, es una tautologa.
Disjunctive Normal Form (DNF), que consiste en dejar todo como

proposiciones atmicas (negadas o no) enlazadas entre s por
conjunciones y stas a su vez enlazadas por disyunciones.
(
in=1 mj=1 Ai , j ) [Expr. 3.9]
69
De este modo, si todas las subfrmulas contienen F o proposiciones

atmicas complementarias, es imposible.
Negation Normal Form (NNF), que consiste en que slo estn

negadas las proposiciones atmicas, no quedando ningn parntesis
negado. Se utilizar para el procedimiento Tableaux.
Horn Form (HF), que consiste en dejar todas las subfrmulas con
como mximo una proposicin sin negar (no siempre es posible esta
transformacin). La parte sin negar es la causa de la implicacin y la
negada es la consecuencia de dicha implicacin. Por ejemplo:
( A C ) (C B A) [Expr. 3.10]
Que se puede transformar en implicaciones (que se utilizan en

lenguajes basados en reglas):
(C A) y ( A (C B )) [Expr. 3.11]
3.2.4.4 Razonamiento en LP
El objetivo del razonamiento en esta y las siguientes lgicas es permitir que
nuestros sistemas inteligentes puedan obtener y comprobar distintas
conclusiones basndose en su base de conocimiento. Por ejemplo, gracias al
razonamiento un sistema, basndose en su conocimiento de que si ha de
encender las luces de la calle cuando est oscuro y en su conocimiento de
que cuando es de noche est oscuro, podr deducir que ha de encender las
luces cuando sea de noche.
Decimos que una KB en lgica proposicional es un conjunto de frmulas

lgicas, de forma que una interpretacin I satisface la KB (es posible) si
satisface todas y cada una de sus frmulas.
I KB sii I A, para todo A KB [Expr. 3.12]
Luego saber si una frmula Z se puede inferir a partir de la KB, se basa en

obligar a que se cumpla Z (sea verdadera) en todas las interpretaciones que
satisfacen la KB.
KBZ sii I Z para todos los modelos I de la KB [Expr. 3.13]

70
Existen dos procedimientos para resolver las inferencias son el

procedimiento de enumeracin el de tableaux.
3.2.4.5 Razonamiento por enumeracin

Este mtodo consiste en poner en una tabla todas las combinaciones
posibles de proposiciones atmicas, ver las que son modelo de KB (las que
dan verdadero en todas las frmulas de la KB) y comprobar que dan
verdadero tambin en la frmula que queremos inferir.
El mtodo realiza un estudio exhaustivo de todas las posibilidades, es decir,

de todos los modelos posibles, que tiene como ventaja que se pueden
realizar todos los tipos de comprobaciones a la vez (posibilidad,
imposibilidad, validez e invalidez). Como desventaja es que conlleva un
gran esfuerzo computacional, ya que dadas N variables hemos de valoras las
distintas 2N posibles combinaciones de verdadero o falso.
Podemos ver un ejemplo en la figura 3.1, donde tenemos una base de

conocimiento y queremos averiguar si esa base de esa base de conocimiento
KB se puede inferir la sentencia , .
KB = ( A C ), (B C )
= (A B)
KB ?? (veremos si se puede inferir de KB)
A B C ( A C ) ( B C ) KB I
F F F F F F F 1
F F T T F F F 2
F T F F T F T 3
F T T T F F T 4
T F F T F F T 5
T F T T F F T 6
T T F T T T T 7
T T T T F F T 8
Modelos posibles: 8 (I1I8)
71
KB cierto en {I7}
cierto en {I3, I4, I5, I6, I7, I8}
M ( KB ) M ( ) ( cierto en TODOS los modelos posibles de KB)
KB ?? SI (se puede inferir de KB)
Figura 3.1. Ejemplo de deduccin por Enumeracin
3.2.4.6 Razonamiento por mtodo Tableaux

El mtodo Tableaux es un mtodo ms ptimo computacionalmente que el
razonamiento por enumeracin. Sin embargo, slo puede resolver cuestiones
sobre si un conjunto de frmulas es posible o imposible, con lo que
tendremos que realizar algunas modificaciones para llegar a otras
conclusiones.
El mtodo Tableaux consiste en reducir el sistema en su forma NNF de

conjunciones y disyunciones (ser el nodo raz de nuestro rbol Tableaux)
Luego ir descomponiendo las hasta quedarse con todo descompuesto. En la
figura 3.2 podemos ver un ejemplo, donde se comprueba la posibilidad de
una frmula, consistente en tres subfrmulas.
Se comienza con todas las frmulas que son conjunciones, colocando en

cada nodo de la rama los valores atmicos de las mismas (por ejemplo,
podemos ver en la figura 3.2 que colocamos B y C). Luego por cada
disyuncin se dividir la rama, generando dos nodos paralelos con los
valores atmicos de la disyuncin (por ejemplo, en la figura 3.2 podemos
ver una rama A y otra con C). En cada formacin de un nodo se comprueba
que los valores que anoto no contradicen a sus nodos predecesores en la
rama hasta la raz (que no hay en un nodo X y en uno anterior de su rama
X). Terminaremos de recorrer una rama cuando hay una contradiccin o
cuando terminamos con todas las subfrmulas.
Si terminamos de recorrer una rama sin llegar a una contradiccin del tipo
X y X, hemos encontrado una Interpretacin que lo cumple, por lo que el
conjunto de frmulas es posible. Si recorremos todas las ramas del rbol y
todas llegan a contradiccin, es que el sistema es imposible.
72
( A C ), (B C ), ( A B )
Posible??
(A C )
( B C )
(A B)
B
C
A C
Imposible,
pasar a otra
rama
B
POSIBLE
A=T
B=T
C=F
1. Por cada conjuncin se sigue la rama

2. Por cada disyuncin se divide la rama
3. Se sigue hasta que una rama es imposible (contradiccin) o se han
dividido todas las frmulas a tomos (A, B, C)
4. Si todas las ramas son imposibles, el sistema es imposible
Figura 3.2. Ejemplo de Tableaux
Tableaux es ms eficiente (si partimos de la forma NNF) que la

Enumeracin, ya que no es necesario recorrer todas las posibilidades.
73
Para saber otras deducciones distintas de las de posibilidad e imposibilidad

en un conjunto de frmulas, tendremos que realizar transformaciones. Por
ejemplo, si queremos saber si una frmula se puede deducir de una base
de conocimiento KB (KB ), bastar con ver si es posible que se den KB y
a la vez. Si es imposible, podemos deducir que KB .
KB = ( A C ), (B C )
= (A B)
= (A B )
( A C ), (B C ), (A B )
Posible??
(A C )
( B C )
(A B )
B
C
A
B
Imposible, y no
hay mas ramas
KB ?? SI
Figura 3.3. Ejemplo de deduccin Tableaux
74
3.2.5 Lgica de Primer Orden (FOL)

La Lgica de Primer Ordern (First Order Logic o FOL) se puede ver como
una ampliacin de la lgica proposicional [IAN03], aadiendo sintaxis
respecto a los cuantificadores (quantifiers), la semntica con
interpretaciones de trminos cuantificados y aumenta el significado de las
frases de lgica predicativa. La razn por la que se hace dicha extensin es
para intentar adentrarnos en la estructura de las sentencias atmicas de la
lgica proposicional, que son slo frases que pueden ser verdaderas o falsas
pero sin estructura interna. En FOL [FRA01], las frases atmicas se
interpretan como aserciones sobre relacin entre objetos (relaciona n
objetos, n>=1).
Veamos el ejemplo 3.1: La pelota es redonda
REDONDA(pelota) [Ej. 3.1]
Donde pelota es un objeto y REDONDA es una propiedad de dicho objeto

(smbolo predicativo).
Adems, cuando se utilizan cuantificadores se pueden colocar variables en

los predicados. Podemos verlo en el ejemplo 3.2: Hay pelotas que son
redondas y verdes
x.[REDONDA( x) VERDE ( x)] [Ej. 3.2]
3.2.5.1 Sintaxis en FOL

La sintaxis se puede resumir segn la tabla 3.5 [FER06]:
Trminos, que pueden ser constantes (individuos), variables o

funciones de trminos.
Literales, que son frmulas atmicas (Tienen predicados P), y
negaciones de las mismas
Frmulas generales, que aaden conectores lgicos (lgica
proposicional) y cuantificadores.
Smbolo Denominacin descripcin

a, b constante Un objeto de nuestro mundo
x, y variables En el momento de hacer la
75
asercin puede ser cualquier

constante de nuestro mundo
f(t1,tn) ti=a x F(t1,tn) (trminos)
f(a1,an) Trminos Trminos que no incluyen
bsicos variables
, P(t1 ,.., t n ) frmulas Trminos relacionados por un
atmicas smbolo predicativo P
T verdadero
F Falso
negacin
conjuncin
disyuncin
implicacin
equivalencia
x.[ ] Cuantificador Nos referimos a al menos uno
existencial de los objetos que cumple
x.[ ] Cuantificador Nos referimos a todos los
universal objetos que cumplen
Tabla 3.5. Sintaxis FOL
3.2.5.2 Semntica en FOL

En esta lgica [FRA01], llamaremos Interpretacin I
I = , I [Expr. 3.14]
donde es un conjunto no vaco y I es una funcin que mapea:
a) Los smbolos de funcin sobre
[
f I n ] siendo n el orden de f [Expr. 3.15]
una funcin es cierta si en nuestra interpretacin existe dicha funcin

y su resultado pertenece a nuestro conjunto .
( f (t1 ,K, t n ))I ( I I

)
f I t1 , K , t n [Expr. 3.16]
b) Las constantes sobre elementos de
76
aI [Expr. 3.17]
Una constante es cierta en una interpretacin si se refiere a un objeto

de dicha interpretacin.
c) Los smbolos de predicados (predicativos) en relaciones sobre n
P I n siendo n el orden de P [Expr. 3.18]
Una frmula atmica es cierta (se cumple) en una interpretacin si

los objetos a los que se refiere se relacionan entre s por medio de P.
I P(t1 ,K , t n ) [Expr. 3.19]

I I
sii t1 , K , t n PI
d) El conjunto de variables V se asignan segn una asignacin (por

ejemplo, si mi sistema tiene 2 variables x e y, su asignacin podra
ser x = pelota, y = sombrero, si pelota y sombrero pertenecen a ).
:V [Expr. 3.20]
I ,
x = ( x) el objeto asignado a x por
a I , = a I
( f (t1 ,K, t n ))I , (
f I t1
I ,
,K, t n
I ,
)
I , P(t1 ,K , t n )
I , I ,
sii t1 ,K, t n PI
[x / d ] indica que hacemos la asignacin menos para x, que lo

sustituimos por d .
Se dice que una frmula es verdadera en una interpretacin I bajo una

asignacin de variables si la interpretacin I haciendo la sustitucin de
variables son algn modelo posible de .
I , [Expr. 3.21]
La semntica de FOL se puede ver en la tabla 3.6.
77
Sintaxis Significado
I , P(t1 ,K, t n ) t1
I ,
,K, t n
I ,
PI
I ,
I , , no se satisface en I ,
I , I , y adems I ,
I , I , o (no exclusiva) I ,
I , Si I , entonces I ,
I , I , , si y slo si I , ( en
esa interpretacin I , )
I , x.[ ] Para todo d : I , [x / d ]
I , x.[ ] Existe al menos un d : I , [x / d ]
Tabla 3.6. Semntica FOL
Las frmulas en FOL se dividen como en la Lgica Proposicional (posible,

imposible, vlida o invlida), pero esta vez respecto a la un modelo I bajo
, (I , ) .
Una frmula es cerrada (sentencia) si no tiene variables en su interior, no

dependiendo de .
A las relaciones entre operadores de la Lgica Proposicional hay que aadir

los de los cuantificadores (Tabla 3.7):
Frmula Equivalente
x.[y.[ ]] y.[x.[ ]]
x.[y.[ ]] y.[x.[ ]]
x.[ ] [x[ ]]
x.[ ] [x[ ]]
[ x.[ ]] = [ x.[ ]],

{, }, si no depende de x,
{,}

suele lle var dentro ej x.[ ]
suele lle var dentro ej x.[ ]
x.[y.[ ]] y.[x.[ ]]
x.[y.[ ]] y.[x.[ ]]
78
Tabla 3.7. Equivalencias de cuantificadores
En FOL podemos incluir el concepto de herencia, por medio de la inclusin

(subsumption). Dados P y Q como smbolos predicativos del mismo orden,
se dice que P incluye a Q en la Teora KB:
KB P Q [Expr. 3.22]
Si para todo objeto o n-tupla de objetos que se relacionan por Q, tambin se

relacionan por P
KB x1 ,Kx n .[Q( x1 ,K x n ) P( x1 , K x n )] [Expr. 3.23]
Por ejemplo, FAMILIAR incluye a HERMANO, si ambos relacionan a dos

seres (todas las relaciones de hermandad dos a dos son a su vez relaciones
de familia). Esto se puede ver como una cierta herencia entre los distintos
smbolos predicativos.
Si la propiedad es de grado 1 (slo se refiere a un objeto), se puede entender

dicha propiedad como la definicin de una clase y la inclusin como una
herencia entre clases.
Por ejemplo, decir que Juan es Profesor, PROFESOR (Juan), sita a Juan
como miembro de la clase profesor. Y si digo que
PROFESOR TRABAJADOR, puedo concluir que Juan tambin pertenece
a la clase de los trabajadores, TRABAJADOR (Juan).
3.2.5.3 Formulacin en FOL

Las frmulas se pueden expresar siempre en la forma Prenex Normal Form
(PNF):
Eliminar todos los , .
Meter dentro de los parntesis todas las negaciones (Hasta aqu

parecido a NNF).
Sacar al mximo fuera de los parntesis los cuantificadores.
Existe un procedimiento para resolver el problema de si un sistema es

posible (Tableaux para FOL):
79
La mecnica es parecida a la utilizada en Tableaux para Lgica

Proposicional. Necesita su forma NNF (PNF).
Se aade que: se atacan primero los , y se substituye la variable

por una constante totalmente nueva. Cuando hay lo que se hace es
sustituir la variable por todas constantes que tenemos, unidas entre si
por conjunciones.
Un punto que afecta a los problemas a resolver en FOL es si es resoluble

(decidable). Un problema es resoluble si hay algn proceso computacional
que resuelve el problema en un nmero finito de pasos. En el caso de FOL
est demostrado [SCHO89] que el problema de averiguar si una frmula se
deduce de una base de conocimiento es irresoluble. Sin embargo, De hay
razonadores para FOL como Vampiro[RIA02] o E-SETHEO [MOS97], que
normalmente se basan en la bsqueda de incongruencias en una base de
conocimiento, utilizando procedimientos no completos, por lo que no
podemos asegurar que si el razonador no encuentra incongruencias no las
haya.
Para hacer la lgica resoluble hemos de restringir FOL. Una de las

posibilidades que simplifica mucho los razonadores es restringir FOL
utilizando como mucho dos variables en los smbolos predicativos ( L2 ).
Existen a su vez sistemas ms complejos de resolver que FOL[IAN03], a la

vez que ms expresivos. Por ejemplo en Lgicas de Mayor Orden (HOL),
donde se permite libremente el uso de variables en los smbolos
predicativos, y aunque por su complejidad de resolucin son intratables para
sistemas grandes, existen razonadores, como HOL [GOR93] e Isabelle
[PAU94]. De hecho, otra definicin para FOL se basa en que el clculo de
lgica predicativa FOL permite variables para referirse a objetos pero no a
predicados o funciones.[LUG02].
3.2.6 Lgica Descriptiva DL

3.2.6.1 Introduccin
Las Lgicas Descriptivas (DLs) pueden ser vistas como el subconjunto de
FOL que permite hacer resoluble sus inferencias [TSA03]. DL fue diseado
como una extensin de frames (sistemas computacionales) y de las redes
semnticas. Recibi el nombre de Lgica Descriptiva en los 80, llamndose
80
anteriormente lenguajes conceptuales (concept lenguajes) y anteriormente

sistemas terminolgicos (terminological systems).
El primer sistema basado en DL fue KL-ONE[BRA85], viniendo despus

LOOM (1987), BACK (1988), KRIS (1991), FaCT (1998) y Racer (1999).
Hoy en da es una de las bases de la Web Semntica.
los lenguajes DL no son los nicos subconjuntos de FOL resolubles

[SER02], ya que hay otro conjunto de lenguajes Horn (basados en reglas,
como PROLOG[GUP01]) y F-Logic [KIF95].
Segn [BEN02], DL son una familia de formalismos de representacin de

conocimientos diseados para representar y razonar sobre ontologas, y otras
cosas como esquemas de bases de datos, configuraciones, etc.
Los sistemas DL se basan en una KB que contiene aserciones sobre las

clases o dicho de otra forma una taxonoma de clases (terminologa, T-Box)
y un conjunto de aserciones sobre instancias, o dicho de otra forma,
representacin de una situacin concreta (A-Box). Sobre esta KB se pueden
realizar inferencias (Ver Figura 3.4).
Buscando una cierta analoga con las Bases de Datos, T-Box sera la
descripcin de la Base de Datos (esquemas) y A-Box las tuplas de esa Base
de Datos.
T-Box contiene:
Definiciones de Conceptos (les asigna un nombre)
AC [Expr. 3.24]
siendo en la expresin 3.24 A el nombre del concepto y C su

definicin (concepto complejo). En el ejemplo 3.3, la clase de los
profesores son las personas que imparten al menos una materia:
profesor persona IMPARTE.materia [Ej. 3.3]
Axiomas (restringe el modelo)
C1 C2, Ci son conceptos complejos [Expr. 3.25]
81
El ejemplo 3.4 representa el axioma Todo alumno es tambin una

persona. Otra forma de entender el axioma del ejemplo es indicar
que la clase alumno es subclase de la clase persona.
alumno persona [Ej. 3.4]
A su vez las A-Box contienen:
Aserciones sobre conceptos.
a:C [Expr. 3.26]
siendo a el nombre de una instancia que pertenecer al concepto C.

Por ejemplo (ejemplo 3.5): Juan es un profesor y adems ingeniero
(pertenece al conjunto de los profesores y al conjunto de los
ingenieros.
Juan : profesor ingeniero [Ej. 3.5]
Aserciones sobre roles.
(a,b): R R(a,b) [Expr. 3.27]
siendo a, b objetos de nuestro sistema y R un rol (propiedad) de nuestro

sistema. En el ejemplo 3.6 podemos ver las dos formas de representar una
asercin sobre un rol, en la que indicamos que la instancia Juan est
relacionada por medio de la propiedad IMPARTE a la instancia Telemtica.
(Juan, Telemtica): IMPARTE [Ej. 3.6]

IMPARTE(Juan,Telemtica)
En la figura 3.4 podemos ver una representacin grfica de la arquitectura

de un sistema de Lgica Descriptiva, en la que hemos utilizado los ejemplos
anteriormente comentados. La T-Box contiene informacin relacionada
nicamente con las clases, por lo que la podemos considerar como la parte
del conocimiento general. En la A-Box se sita la parte de nuestra Base de
Conocimiento relacionada con las instancias, por lo que podemos considerar
a la A-Box como la parte ms concreta de nuestra Base de Conocimiento, la
que trata de casos particulares.
82
Base de Conocimiento, KB
INFERENCIAS
T-Box
profesorpersona (IMPARTE.materia)
alumno persona
ingeniero persona
A-Box
Juan: profesor ingeniero
Telematica : materia
(Juan, Telematica): IMPARTE
Figura 3.4. arquitectura de un sistema DL
3.2.6.2 Sintaxis y Semntica en DL

Existen varios lenguajes de lgica descriptiva, siendo todos en cualquier
caso un subconjunto de la sintaxis de FOL (aunque la notacin se
simplifica). Los distintos lenguajes de lgica descriptiva los veremos en el
apartado siguiente.
Para estudiar la sintaxis veremos como ejemplo el lenguaje denominado

ALC, [ALO06]. ALC, es el lenguaje DL ms simple y restrictivo, con slo
predicados binarios y que relacionan instancias abstractas (no nmeros,
strings u otro tipo de dato definido, ni siquiera por medio de la enumeracin
de sus elementos). Adems, no permite asignar propiedades a los roles
(como indicar que un rol es transitivo). Pese a ser ALC, el lenguaje ms
sencillo, el resto utilizan la misma sintaxis, aadiendo slo las propiedades
de los roles. En la tabla 3.8 se muestra su sintaxis.
Sintaxis Semntica Significado

C I Concepto simple, primitivo o
C I
atmico. Es un subconjunto de
I
R RI I x I Rol simple, primitivo o
atmico (binario)
83
C D CI DI Conjunto de elementos
definido por la unin de dos
conceptos (unin de
conjuntos)
C D CI DI Conjunto de elementos
definido por la interseccin de
dos conceptos (interseccin de
conjuntos)
C /C
I
Conjunto de elementos que
abarca todo nuestro espacio
menos los individuos que
agrupa C
I I
R.C {x | y.[R (x,y) C (y)] Conjunto de elementos que se
relacionan al menos una vez
por medio de R con otros
elementos pertenecientes al
concepto C
I I
R.C {x | y.[R (x,y)C (y)] Conjunto de elementos que
tienen todas sus relaciones con
otros elementos pertenecientes
al concepto C por medio de R,
y no por otro medio.
T I Todo nuestro espacio (top)
El conjunto vaco (botton)
Tabla 3.8. sintaxis y semntica de ALC
A continuacin describimos la semntica relacionada con DL. Dada una

interpretacin I, que vemos en la ecuacin 3.28, definimos una Teora del
Modelo (Model Theory, MT).
(
I = I , I ) [Expr. 3.28]
La Teora del Modelo indica las reglas bsicas de mi abstraccin de la

realidad. En esta teora los nicos elementos simples son las instancias de
los objetos y las instancias de parejas de objetos. Tanto los roles simples
como los Conceptos simples, son conjuntos de [ I ] y [ I x I ]
respectivamente. Esto ocurre tambin en el MT de FOL [IAN03].
84
Juan, Telemtica, Pedro, Redes, profesor, despistado, IMPARTE
I I
I x I
J (P,R)
(J,T)
P
(J,P)
T (P,J)
(T,J)
R (J,R)
(R,J)
(P,T)
(T,P)
(R,P)
(T,R)
(R,J)
Figura 3.5. Ejemplo de MT
3.2.6.3 Tipos de DL
Se distinguen entre s por el subconjunto de FOL que abarcan. Cuando ms
abarcan, ms expresivo es el lenguaje, pero a su vez ms complicado es
razonar en esa lgica. En la tabla 3.9 podemos ver una comparativa de los
distintos sistemas, indicando las caractersticas de los mismos y ordenados
de menor a mayor complejidad [IAN02], [PAN02].
85
Como veremos ms adelante, el lenguaje que utilizaremos en esta Tesis para

describir nuestra ontologa, OWL, dispone de varios niveles de
expresividad. Segn su nivel, implementa uno u otro lenguaje de lgica
descriptiva, por lo que es importante considerar y ponderar la expresividad
del lenguaje y la complejidad de los razonamientos, para elegir el nivel de
OWL ptimo.
Nombre Componentes Complejidad

ALC , ,,R.C, R.C ExpTime-c
S ALC + roles transitivos ExpTime-c
SI S + roles inversos(I) ExpTime-c
SH S + jerarqua de roles (H) ExpTime-c
SHIQ SHI + restricciones ExpTime-c
numricas (OWL LITE)
SHIQ0 SHIQ + nominales (OWL NExpTime-hard
DL)
SHIQ0(D) SHIQ0 + Datatypes orden 1 NExpTime-hard
SHIQ0(Dn) SHIQ0 + Datatypes orden n NExpTime-hard
SHIQ+ SHIQ + rest. Numricas en No resoluble
cualquier sitio
SH+ SH + rest. Numricas en No resoluble
cualquier sitio
Tabla 3.9. Lgicas DL
En la tabla 3.9 podemos ver rdenes de complejidad con un coste temporal

exponencial respecto a la complejidad de nuestro problema (nmero de
elementos), llegando a no ser resoluble en los lenguajes ms expresivos. Los
aumentos de expresividad principales son por la inclusin de:
Roles transitivos, cuando a est relacionado con b y b est

relacionado con c por la misma propiedad:
R(a,b) R(b,c) R(a,c) [Expr. 3.29]
Roles inversos, un Rol es inverso a otro cuando al aplicar ambos el

elemento sobre el que se aplica da como resultado el mismo
elemento.
R: R(R(x)) x [Expr. 3.30]
86
Jerarqua de roles, cuando un Rol es una especializacin de algn

otro, por lo que los elementos que se relacionan con el rol hijo
tambin se relacionan con el rol padre. Pongamos como ejemplo que
el Rol serHijoDe es una especializacin de serFamiliaDe, por lo que
todo elemento que se relacionen con otro por medio del Rol
serHijoDe se relacionar tambin por medio del Rol serFamiliaDe.
R P [Expr. 3.31]
Nominales. Los nominales nos permitirn definir una clase

enumerando uno a uno los elementos que la contienen: Por ejemplo,
la clase de das de la semana incluira a {Lunes, Martes, Mircoles,
Jueves, Viernes, Sbado, Domingo}
Restricciones numricas: n, n {1,2,}. Lo comn es

restringirlas a los Roles. Por ejemplo:
3IMPARTE.Materia [Expr. 3.32]
Tipos de Dato (Datatypes). Los tipos de datos son nmeros, strings,

etc, que se estudian como un conjunto disjunto de , llamado D ,
I I
definiendo unos nuevos tipos de Roles (en este caso se denominan

propiedades/predicados de tipos de datos (datatype properties)). Por
ejemplo, EDAD(JUAN) relaciona a Juan con el tipo de dato entero
35.
3.2.6.4 Razonamiento en DL
Al haber separado la KB en dos bloques, el razonamiento se divide tambin

en 2 partes:
1. Razonamiento en la T-Box:
Posibilidad de un concepto. Ver si un concepto es posible

(Concept Satisfiability). Consiste ver si existe un modelo
para un concepto (al menos un individuo que lo cumpla).
Inclusin (Subsumption). Consiste en comprobar si una

nueva asercin se puede inferir directamente de las
87
aserciones de la T-Box. Si es as, se dice que la nueva

asercin introducida no aporta nueva informacin a nuestro
sistema.
Posibilidad (Satisfiability). Es ver si existe algn modelo

para esa T-Box. Es decir, no hay ninguna
incongruencia/inconsistencia en dicha T-Box. Una clase es
inconsistente si en todas las interpretaciones de nuestro
sistema esa clase es el conjunto vaco. La T-Box se define
como inconsistente si en todas las interpretaciones existe
alguna clase que no puede tener individuos
Los tres casos se pueden reducir a Posibilidad [BEN03].
2. Razonamiento en la A-Box:
Comprobar si una instancia pertenece a una clase

determinada (Instance Checking o Inferred Types). Por
ejemplo, saber si Juan pertenece a la clase [profesor
ingeniero].
Consistencia. Si lo que decimos en la A-Box es coherente

con ella misma y con lo descrito en la T-Box. Por ejemplo, si
decimos que Juan es ingeniero y que Juan no es ingeniero.
Actualmente hay pocos razonadores que manejen razonamiento en la A-

Box. Uno de los ms utilizados es Racer (Reasoner for Aboxes and
Concept Expressions Renamed)[WWW13].
3.2.6.5 Suposicin de mundo abierto (OWA)

Una de las razones por las que DL ha sido escogido para la implementacin
de web semntica es que no supone que el conjunto de aserciones que tiene
su A-Box es invariante, y que se contiene toda la informacin necesaria para
resolver cualquier problema.
Por ejemplo, si en nuestra A-Box hablamos de profesor Juan que imparte

dos materias pertenecientes a Sistemas de Informacin, esto no nos permite
inferir que TODAS las materias que imparte el profesor son de Sistemas de
Informacin, ya que puede que descubramos en algn momento que imparte
otro tipo de materias. Slo podramos asegurarlo si:
88
1. Decimos que un profesor puede dar como mximo 2 materias (si

nuestra DL permite restricciones numricas).
Profesor: (2 IMPARTE)Materias [Expr. 3.33]
2. Aadimos directamente la asercin de que Juan slo da materias de

Sistemas de Informacin.
Juan: IMPARTE.Materias_SI [Expr. 3.34]
Esto nos permitir trabajar de forma incremental en la web, segn vaya

apareciendo informacin nueva o los agentes la vayan descubriendo. Debido
al tamao y la velocidad de cambio de la web, la suposicin de un mundo
cerrado sera inapropiada [OWL04A].Supongamos que utilizramos un
agente que realizara inferencias bajo la suposicin de mundo cerrado. Como
la cantidad de informacin existente en la web es enorme y va creciendo,
por razones de espacio y tiempo para el almacenamiento, le sera imposible
almacenar toda la informacin disponible en la web. Adems, aunque
recogiera una gran cantidad de informacin, cuando realizara inferencias y
apareciera publicada nueva informacin al respecto en la web, debera de
realizar de nuevo las inferencias, que podran darle resultado diferentes.
Sin embargo, trabajando con la suposicin OWA, el agente en principio

coger la informacin mnima necesaria hasta llegar a la inferencia que
busca, y en caso de aparecer nueva informacin, slo ha de comprobar que
esa nueva informacin no contradice a la ya existente en su base de
conocimiento. Si no hay contradiccin, los razonamientos previos a la
introduccin de la nueva informacin son igualmente vlidos.
Bajo la suposicin OWA, que permite la incorporacin de aserciones

nuevas, puede darse el caso de que se introduzca nueva informacin en
nuestro sistema que afecte a la T-Box. Se denomina Clasificacin a la tarea
de insertar nuevos conceptos a la Taxonoma, que puede hacer aparecer
clases inconsistentes y relacionar clases entre s [FRAN02].
3.2.6.6 Suposicin de nombres nicos (UNA)

Esta suposicin indica que dos instancias con dos URIs distintas son
necesariamente instancias diferentes. Esta suposicin simplifica los queries
y adems hace que no se enve una gran cantidad de informacin. El ahorro
de envo se informacin se debe a que, si no hay suposicin de nombres
nicos, he de indicar explcitamente qu instancias son distintas entre s.
89
Sin embargo, el lenguaje ontolgico que vamos a utilizar (OWL) no permite

hacer esta suposicin de nombres nicos. Dos URIs distintas pueden, a no
ser que se demuestre lo contrario, representar al mismo recurso. Esto nos
obliga a realizar grandes cantidades de aserciones cuando tenemos claro que
los recursos representan objetos reales completamente diferentes.
Por otro lado, se adapta ms a los sistemas web en los que no se dispone de
toda la informacin desde el principio. Al ser la web un sistema distribuido
en el que la informacin sobre una misma instancia puede venir de dos
fuentes distintas, sera inviable centralizar la asignacin de URIs a
instancias. Al no realizar la suposicin de nombres nicos, puedo ir
recogiendo informacin de varias fuentes y luego relacionarlas segn vaya
descubriendo que dos URIs son realmente la misma instancia. Realizando
un smil en la vida real, puedo recibir informacin acerca de un primo
lejano, y a su vez informacin acerca del nuevo novio de una amiga de mi
mujer. Meses ms tarde puedo llegar a descubrir que ambas personas son en
realidad la misma.
Trabajar con un razonador que permita que varios nombres sean la misma
instancia nos obliga a ser cuidadosos con la informacin que introducimos
en el sistema, ya que estamos obligados a indicar las clases que son
disjuntas y las instancias que son distintas para evitar razonamientos
errneos. Como ejemplo supongamos que pongo una restriccin consistente
en que un humano slo puede tener un padre. Si indico que el padre de Juan
es Pedro y luego introduzco que el padre de Juan es ngel, en lugar de
indicar que existe una incongruencia en la informacin facilitada, concluir
que ngel es la misma persona que Pedro.
3.3 Lenguajes ontolgicos

3.3.1 Introduccin
Existen mltiples definiciones de ontologa, segn hablemos de trminos
filosficos, lingsticos o de sistemas de informacin. Ontologa, en
trminos de sistemas de informacin (nuestro mbito) se puede entender
como una especificacin explcita de una conceptualizacin [GRUB93].
Una ontologa define los trminos usados para describir y representar un

rea de conocimiento [OWL04A] (como medicina, arte, etc). Las
ontologas se utilizan por la gente y por sistemas computacionales para
90
compartir informacin de un dominio (entendiendo como dominio una

porcin determinada de un rea de conocimiento).
Las ontologas se componen de
Objetos o instancias, que podran ser una representacin de un

objeto en la realidad (por ejemplo, la mesa de mi despacho).
Tambin se conocen como instancias, o individuals.
Clases, que representan a un conjunto de objetos. Aunque la palabra

concepto se utiliza a veces como sinnimo [IAN03], otros autores
[HOR04] relacionan estas dos definiciones diciendo que las clases
son concretas representaciones de los conceptos (ideas que
tenemos en la mente).
Las propiedades que esos objetos pueden tener, siempre dentro de

nuestro dominio de inters. Tambin se conocen como roles, slots o
atributos.
Relaciones que pueden haber entre dichos objetos, que la mayora

de lenguajes ontolgicos agrupan dentro de las propiedades de
dichos objetos.
Una ontologa se expresar en un lenguaje basado en sistemas lgicos

(lenguaje ontolgico) que servir para almacenar nuestro conocimiento
sobre el dominio de inters. Algunos autores utilizan el trmino teora para
referirse a estas ontologas, ya que a veces son relativamente pequeas y se
pueden completar con otras teoras [MAR02]. Las ontologas tienen
caractersticas diferenciadoras respecto a una base de datos que almacene la
informacin de nuestro sistema, donde las tablas sean clases, las tuplas de
las tablas instancias y las relaciones entre instancias relaciones simples o
mltiples entre los identificadores de las tablas. Los elementos
diferenciadores entre una ontologas y la informacin almacenada en una
base de datos son:
Permiten que los objetos tengan propiedades (seran los equivalentes

a campos de una tabla de base de datos) que no estn en la definicin
de la clase a que pertenecen. Cuando definimos una tabla que
contiene la informacin de un objeto, hemos de indicar a priori el
nmero de campos y el tipo de datos a almacenar en cada campo.
91
Permiten mltiples definiciones de clases y propiedades. En una

base de datos normalmente existe una tabla fija para el
almacenamiento de informacin de un objeto.
La informacin sobre un objeto no tiene por qu estar solamente en

un documento (aunque es cierto que existen bases de datos
distribuidas, en estos lenguajes se permite mayor libertad). Adems,
puede ir apareciendo informacin en documentos distintos.
No se supone nunca que se tiene un conocimiento total de nuestro

dominio de inters, por eso existen frases como las pizzas tienen al
menos un ingrediente, junto con informacin de algunas pizzas en
las que no sepamos ningn ingrediente.
Al estar basados en lenguajes lgicos, podrn procesarse inferencias

(deducciones), que podrn realizar sistemas no humanos. No se
pueden realizar muchas inferencias automticas basndonos en una
base de datos.
Estas caractersticas nos permitirn utilizar las ontologas para mejorar las
aplicaciones Web que dispongamos, ya sea para generar directamente
portales sobre temticas determinadas (como por ejemplo OntoWeb
[WWW3], WordNet [WWW4] u Ontolingua [WWW5]), para describir
fuentes en internet (fuentes multimedia, u otras entidades, como objetos de
aprendizaje), para describir la capa lgica de un sistema de tres capas, para
disear cmo ha de ser la documentacin de algo (y poder hacer luego
consultas a esa documentacin por medio de algo ms que el ndice y buscar
las palabras), para su uso por agentes inteligentes (que veremos ms
adelante), o incluso para describir los propios servicios que un sistema
puede ofrecer (OWL-S).
3.3.2 Tipologa de lenguajes ontolgicos

Existe una gran cantidad de lenguajes ontolgicos, lo que nos obliga a
realizar una taxonoma de dichos lenguajes. Una primera clasificacin sera
[BECH03]:
1. Lenguajes para representaciones grficas (denominados

Graphical notations). Estos lenguajes no se basan en lenguajes
lgicos, slo en la sintaxis de las ontologas (clases, instancias,
propiedades que las relacionan entre s). Si bien en este trabajo no se
92
considerarn como lenguajes ontolgicos, por su deficiencia en

lgica para poder realizar inferencias, s son la base para la gran
mayora de lenguajes ontolgicos y para representar ontologas
grficamente. Dentro de este grupo encontramos:
las redes semnticas, entendidas como un conjunto de nodos

relacionados entre s por flechas. Hay sistemas ontolgicos
fuertemente relacionado con ellos, como WorldNet [WWW4],o
sistemas de enseanza basados en conceptos, como
AHA!(Adaptative Hypermedia Architecture) o AIMS (Agent-
based Information Management System )[ARO02].
los mapas de conceptos (denominados en ingls topics maps

[WWW7]), entendidos como una ampliacin de las redes
semnticas incluyendo el concepto de ocurrencias, que son
referencias a fuentes externas al mapa de conceptos (por ejemplo
una referencia bibliogrfica). Sistemas como Citeseer [WWW9]
utilizan estas uniones externas (almacena uniones con los
documentos en otros lugares fuera de Citeseer). Ejemplos de
lenguajes basados en este sistema son el XML Topic Map (XTM
[WWW10]) y el ISO/IEC 13250[WWW11].
UML (Unified Modeling Language [WWW8]), que como

lenguaje que permite representar objetos y sus relaciones (aparte
de otras muchas posibilidades) se puede entender como uno de
estos lenguajes.
RDF (Resource Description Framework[WWW2], que

desarrollamos ms en profundidad en otros apartados.
2. Lenguajes basados en lgica. Los lenguajes lgicos se pueden

definir como lenguajes formales para representar la informacin, de
forma que se puedan inferir conclusiones. Conllevan una sintaxis,
que define el tipo de sentencias que pueden darse en el lenguaje, y
una semntica, que define el significado de dichas sentencias. Los
lenguajes utilizados para describir ontologas, y que se basan en
lenguajes lgicos son los Lenguajes basados en lgica. Estos
lenguajes se considerarn en esta Tesis como leguajes ontolgicos,
ya que incluyen en su sintaxis definiciones lgicas que permiten
93
utilizar razonadores lgicos para inferir resultados. Segn la lgica

utilizada tenemos:
Basados en Lgica Descriptiva (DL Description Logics). En

este caso tenemos OIL, DAML+OIL, OWL. Estos lenguajes son
los que trataremos en la Tesis, por lo que los describiremos con
ms detalle en otro apartado.
Basados en lgica de primer orden (FOL First Order Logic),

como es el caso de KIF (Knowledge Interchange Format) y sus
sub-lenguajes. Se pude decir que la lgica de primer orden
comprende a su vez la lgica descriptiva. Tambin trataremos
sobre KIF en los siguientes apartados.
Basados en Reglas (denominadas en ingls como Rules), como

RuleML [WWW12], LP/Prolog [GUP01]. Una regla en este caso
se entiende como unidades de conocimiento autocontenidas que
implican algn tipo de razonamiento [WAG03]. En cierto modo
se puede decir que la lgica clsica es un subconjunto de las
posibles reglas. Otros ejemplos de reglas son reglas de reaccin
(cuando pase X, hacer Y), y otros que veremos ms adelante
cuando hablemos de RuleML y SWRL.
Grficos conceptuales (CG conceptual graphs), sistemas

basados en los grficos de Charles Sanders Peirce y utilizados
para sistemas de inteligencia artificial.
Basados en lgicas de mayor orden, como LBase. El mayor

orden en este caso se refiere sintcticamente, es decir poder
relacionar conjuntos de elementos de discusin (y no slo
parejas) directamente, sin hacerlo a pares.
Lgicas no clsicas (F-logic, Non-Monotonic). Estas lgicas no

se basan en el concepto de verdadero o falso, sino en grado de
verdad (probabilidad) de una asercin. Estos lenguajes no sern
tratados en este estudio.
Lgicas probabilsticas o difusas (fuzzy logics) Estos lenguajes

suelen ser utilizados por sistemas de redes neuronales, que no se
estudiarn en esta Tesis.
94
Como en muchos otros sistemas, cuando ms restrictiva es la definicin (en

este caso la lgica utilizada) ms sencillo es su manejo (razonadores ms
rpidos, descripciones ms sencillas, pero ms difcil es que nuestros
problemas reales se adapten a dichos sistemas. Los lenguajes basados en
lgica que se acaban de enumerar se han ordenado de ms restrictivo a
menos, siendo el ms restrictivo los basados en Lgica Descriptiva. Ms
adelante veremos las distintas lgicas arriba mencionadas.
A continuacin veremos los lenguajes ontolgicos ms importantes

utilizados de una u otra forma en internet. Algunos de los lenguajes existan
antes de utilizarse en internet y ahora se utilizan como lenguaje intermedio
entre sistemas y otros lenguajes se han diseado desde cero pensando en la
comunicn via web.
3.3.3 KIF/SKIF
El Knowledge Interchange Format (KIF) [GEN98] es un lenguaje que se
desarroll con la idea de que fuera un lenguaje de intercambio de
conocimiento entre los distintos sistemas desarrollados para tratar el
conocimiento (bases de conocimiento y sistemas de inteligencia artificial).
SKIF [HAY01] se puede considerar como una versin de KIF ms adaptada
a su uso en la Web Semntica (permite el uso de URIs, UNICODE y una
sintaxis ms sencilla, no distinguiendo a priori entre las instancias, las clases
y las relaciones entre ellos (todo se agrupa como trminos). De este modo
podemos decir que algo que es una clase y tiene sus instancias puede ser a
su vez una instancia de otras clases. Por ejemplo, en la figura 3.6, vemos el
Modelo de Teora (MT) de SKIF. En este caso tenemos una ontologa de
enseanza, donde se tiene lugar el caso en el que el trmino Alumno puede
ser una instancia de la clase Miembro (de un curso), y a su vez una clase que
contenga a los alumnos Eva y Juan, y adems podemos indicar que los
alumnos y los profesores se conocen entre s, por medio de la propiedad
CONOCER.
95
Miembro,Unidad, Juan , Eva, Tutor, Alumno, CONOCER
I I
I x I
E (T,A)
(A,T)
J
Figura 3.6. Ejemplo de MT de SKIF
Ambos lenguajes se basan en FOL, y utilizan una sintaxis similar a la

utilizada en el lenguaje deprogramacin declarativa LISP [LUG02], y
mientras son un buen leguaje para intercambio, hay pocos razonadores que
trabajen con SKIF, y normalmente se ha de hacer una transformacin previa
a FOL [IAN03].
96
3.3.4 RuleML
RuleML es un lenguaje basado en reglas, y en principio orientado a su uso
en la Web. Las reglas comprenden a la lgica clsica, de forma que puede
haber reglas en el lenguaje para definir ms profundamente las ontologas.
Las reglas se dividen en distintos tipos, pudiendo en algunos casos
transformar las reglas de un tipo en reglas de otros tipos.
Los tipos de reglas propuestas en RuleML son:
Reglas de Integridad. Sirven para definir, por ejemplo las

restricciones de integridad (integrity constraints) que se colocan en
una base de datos relacional (por ejemplo, una fila de la tabla
facturas tiene un campo id_cliente cuyo valor ha de estar
obligatoriamente como identificador de alguna fila de la tabla
clientes).
Reglas de Derivacin. Se basan en un conjunto de condiciones y

una consecuencia si se dan las condiciones anteriores. Tanto las
condiciones como la consecuencia se representa mediante una
frmula lgica. Por ejemplo, decir que si una factura no est pagada
y tampoco est anulada, entonces la factura es una factura por
cobrar.
Reglas de Reaccin. Estas reglas tienen cierta implicacin

temporal, es decir, tienen un disparador, una condicin de inicio y
una accin a realizar. Hay dos tipos: Evento-Condicin-Accin
(ECA Rules) y Evento-Condicin-Accin-Postcondicin (ECAP
Rules). ECA se pueden ver como los triggers de una base de datos
relacional y los ECAP cuando se expresa de forma abstracta que al
terminar una accin ha de modificar siempre algo (casi como si la
ltima sub-accin de la accin sea modificar X, pero declarndolo
de forma que se puedan inferir resultados de ese dato).
Reglas de Produccin. Expresa qu se ha de hacer cuando se da una

condicin. Son muy parecidas a las reglas de reaccin, con la
diferencia de que una regla de produccin no tiene en s el concepto
temporal de reaccin en el momento que ocurre algo.
Reglas de Transformacin. Son reglas que explican como pasar de

una instancia de un tipo a su equivalente de otro tipo. Por ejemplo,
cmo transformar una instancia compleja de tipo noticia completa
97
a una de tipo resumen de noticia, en el que le decimos se quede

con el titular y el primer prrafo de la noticia.
RuleML se encuentra todava en un estado de desarrollo, y se est

estudiando incluir otros tipos de reglas, como reglas de permisos u
prohibiciones, y reglas de asignacin de tareas.
3.3.5 OWL
3.3.5.1 Introduccin e Historia
El lenguaje ontolgico web (Web Ontology Language, OWL) es un
lenguaje basado en RDFS (lenguaje ya descrito en otro apartado), como
parte de lo que se entiende como Web Semntica.
OWL apareci como recomendacin en febrero del 2004

[OWL04A][OWL04B]. Su diseo se ha visto influenciado por ms de 10
aos de investigacin en Lgica Descriptiva (DL) [HOR03]. Su primer
predecesor se puede considerar SHOE [HEF99], un lenguaje basado en
Frames con caractersticas muy apreciadas en la web:
Una sintaxis construida sobre XML, lo que permita embeberlo

dentro de las pginas HTML.
Los nombres son URIs, lo que le permite reutilizar la gran ventaja

de los nombres nicos de los recursos, y evitar ambigedades.
Suposicin de que las ontologas pueden reutilizarse, cambiar y

ampliarse en el tiempo, por lo que ofrece posibilidades para
importaciones, alias locales para los nombres largos, e informacin
sobre versiones y compatibilidades hacia atrs.
Otro lenguaje que influenci de forma destacable a OWL fue DAML-ONT.

La iniciativa americana DARPA Agent Markup Language (DAML) naci
en 1999 con la idea de ser la base de la Web Semntica. Ya se basaba en
RDFS, pero se decidi enriquecer su sintaxis para aumentar su expresividad,
por lo que se cre el lenguaje DAML-ONT (tambin conocido simplemente
como DAML)[HEN00].
La alternativa europea fue Ontology Inference Layer (OIL), que buscaba

objetivos similares a DAML. OIL fue el primero en basarse en Lgica
98
Descriptiva (de hecho, fue un lenguaje que representaba SHIQ DL), a su vez
de lenguajes basados en Frames y estndares Web. Sin embargo, su
compatibilidad con RDFS no era completa [HOR03].
El antecesor ms cercano de OWL estaba a punto de aparecer. Los esfuerzos

de DAML y OIL se unieron en una iniciativa entre Europa y Estados
Unidos, que se llam DAML+OIL[CON01], que ya se bas en Lgica
Descriptiva y a su vez fue ms compatible con RDFS, aunque surgieron
algunas incompatibilidades cuando sali la versin definitiva de RDF y
RDFS.
OWL es la apuesta de DARPA para la web semntica, ya que permite varios

grados de complejidad (varios niveles), as como una sintaxis robusta y
probada, y un nivel de expresividad alto.
3.3.5.2 Tipos de OWL

Como hemos visto anteriormente, hay varios tipos de Lgica Descriptiva, en
funcin de su expresividad y la complejidad computacional de realizar
razonamientos. Es por esto que OWL se presenta con tres niveles del
lenguaje, en funcin de lo expresivo (y por tanto peor a la hora de inferir)
que sea, lo que nos permite para sistemas ms sencillo limitar la
expresividad buscando una mayor efectividad de clculo. De menos a ms
expresivo tenemos:
OWL Lite, es el ms sencillo y permite una rpida migracin desde

otros lenguajes ontolgicos ms simples. Su lgica tiene unas
restricciones numricas muy limitadas.
OWL DL, que se ha diseado para soportar el lenguaje SHIQO(D) ,

ms expresivo que el anterior pero con un notable aumento de
complejidad (siempre considerando el caso peor), aunque existen
razonadores bastante probados para este sistema (Racer). Los tipos
de datos introducidos son los permitidos por XMLS. OWL DL es el
lenguaje ms apropiado para aplicaciones que requieran el mximo
de expresividad pero que exijan completitud computacional, ya que
todas las conclusiones son computables.
OWL Full, que aunque no aumenta la sintaxis de OWL DL, s que

permite un cambio conceptual grande. Tanto OWL Lite como OWL
Full tienen bien separados las instancias (y los datatypes en OWL
DL), las clases y las propiedades, OWL Full mantiene la relajacin
99
de RDFS, permitiendo que una URI sea una clase y a su vez la

instancia de otra clase, o incluso una propiedad. Esto obliga a que en
OWL Lite/DL cuando hablemos de algo tengamos que decir siempre
si es una clase, una instancia, una propiedad (y de qu tipo), etc. Este
nivel de lenguaje OWL no tiene procedimientos de inferencia
completos y seguros.
3.3.5.3 Constructores y axiomas en OWL

Puesto que OWL es el lenguaje que se va a utilizar en esta Tesis, pasamos a
describirlo con ms detalle. Su sintaxis se divide en constructores, tambin
denominados descripciones de Clase, y axiomas. Los constructores nos
permitirn definir Clases, tanto annimas como no annimas, y los axiomas
sern los elementos por los que podremos realizar aserciones sobre las
Clases y sobre las Instancias de las mismas, as como sobre las Propiedades
que relacionan a las Instancias. Mientras en la definicin formal de OWL
[OWL04b] se consideran los constructores de Clase como un subconjunto
de los axiomas de clase, en esta Tesis hemos separado los dos trminos, ya
que el significado semntico de constructores y axiomas es diferente.
Hemos de remarcar que OWL tiene 3 grupos de propiedades (P)

(constructores de propiedades) (OWL Lite slo una):
Propiedades de instancia (PC), donde el objeto de la propiedad es

un individuo de I (owl:ObjectProperty). Es la nica vlida en OWL
Lite.
Propiedades de tipos de datos (PD), donde el objeto de la propiedad

es un individuo de ID (owl:DatatypeProperty).
Propiedades de anotacin y de ontologa, externas a la parte de

lgica (owl:AnnotationProperty, owl:OntologyProperty) donde se
almacenan breves explicaciones, temas de importacin de
ontologas, versiones, compatibilidad. Los principales tipos
predefinidos son: owl:versionInfo, owl:imports (para definir la
ontologa, junto con otros sobre la compatibilidad), rdfs:label,
rdfs:comment, rdfs:seeAlso, rdfs: isDefinedBy y
Adems se les define a las propiedades rango (rdfs:range) y un dominio

(rdfs:domain).
100
Para las instancias tenemos 2 tipos de constructores:
a) De pertenencia a una clase (aserciones sobre conceptos). Por

ejemplo:
<Profesor rdf:ID=Juan/> [Ej. 3.7]
En este caso definimos las instancia Juan como un elemento de la

clase Profesor.
b) Cuando le damos el valor a una propiedad (aserciones sobre roles).

En el ejemplo 3.8 podemos ver cmo definimos la instancia Juan
existe indicando que la instancia Juan se relaciona con la instancia
Telemtica por medio de la propiedad imparte.
<rdf: Description rdf:about=#Juan> [Ej. 3.8]

<imparte rdf:resource=#Telematica>
</rdf Description>
En las tablas 3.10 y 3.11 vemos la notacin OWL para los constructores de
Clases (Tabla 3.10) y los axiomas (Tabla 3.11), siendo C, D una clase, xi una
instancia, P una propiedad cualquiera, PD una propiedad de tipo de datos, PC
un propiedad de objetos (relaciona un objeto con otro), como ya definimos
en la tabla 3.8.
Constructor Sintaxis DL OWL OWL OWL

Lite DL Full
owl:Class C, [C I I ] X X X
owl:intersectionOf (3) C D X X X
owl:unionOf C D X X
owl:complementOf C X X
owl:allValuesFrom P.C PC P P
owl:someValuesFrom P.C PC P P
owl:maxCardinality nP PC, P P
(1) n={0,1}
owl:minCardinality nP PC P P
n={0,1}
owl:Thing T, [ I ] X X X
owl:Nothig X X X
owl:oneOf (2) {x1,,xn} X X
101
owl:hasValue P=x P x, x X X
Datatype
Tabla 3.10. Constructores de clases en OWL
En la tabla 3.10 se presenta los distintos constructores de clases, es decir,

las formas de definir una clase, indicando el nombre de la clase, o como una
funcin lgica entre otras clases. Tambin se pueden definir con los
cuantificadores de existencia y universal . Tambin se introduce
cuantificadores de cantidad (nP, nP). A modo de aclaracin diremos:
Existe el constructor owl:cardinality, que representa = nP, pero es

derivable de los constructores (1) owl:minCardilatity y
owl:maxCardinality.
En el constructor owl:oneOf(2), para enumerar los individuos se

usan las listas de RDF, utilizando las marcas rdf:List, rdf:first y
rdf:rest. Como simplificacin se puede utilizar el parseador
rdf:parseType=Collection para instancias, donde slo hemos de
enumerar a los miembros [OWL04B].
En OWL Lite el constructor owl:intersectionOf es utilizable slo

cuando se intersecta ms de una clase y slo para intersectar clases.
Esto se hace para evitar que se haga una enumeracin indirecta de
instancias.
Hemos de tener presente que OWL Full relaja las diferencias entre C
(clases), P (propiedades) y x (instancias), por lo que algunos
constructores comparten el mismo significado.
Axioma Sintaxis OWL OWL OWL

DL Lite DL Full
rdfs:subClassOf (1)(3) C1 C2 X X X
owl:equivalentClass (3) C1 C2 X X X
owl:disjointWith C1 C2 X X
owl:sameAs x1 = x2 X X X
owl:differentFrom (2) x1x2 X X X
rdf:subPropertyOf P1 P2 PC P P
owl:equivalentProperty P1 P2 PC P P
owl:inverseOf (4) P1 [P2]- PC P P
102
owl:transitiveProperty P[P] P PC PC PC
owl:functionalProperty (4)(5) T 1P (5) PC P P
owl:inverseFunctionalProperty T 1P- PC PC PC
(4)
owl:SymmetricProperty P[P]- PC PC PC
Tabla 3.11. Axiomas en OWL
Podemos ver en la tabla 3.11 los distintos axiomas del lenguaje ontolgico,
junto con las marcas XML utilizadas para cada uno. Tambin se indican las
diferencias existentes entre los tres niveles de OWL. A modo aclaratorio
podemos especificar los siguiente:
De nuevo debemos tener presente que OWL Full relaja las

diferencias entre C, P y x.(1).
OWL supone que dos URIs distintas pueden referirse a la misma

instancia/objeto/propiedad, por lo que se ha de constatar si son
iguales o distintos explcitamente. Se especifica tambin una
notacin owl:allDifferent para enumerar instancias todas diferentes
entre ellas, pero es el mismo axioma que owl:differentFrom(2).
En OWL Lite slo permite en el uso de los axiomas rdf:subClassOf

y owl:equivalentClass(3) que el sujeto sea un nombre de clase y el
objeto un nombre de clase o propiedad.
En OWL DL, para el uso de los axiomas owl:inverseOf,

owl:functionalProperty e owl:inverseFunctionalProperty (4) no se
permite combinar PC y PD, puesto que el lenguaje OWL DL
distingue entre PC y PD.
Respecto a los tipos de datos, se soportan los de XMLSchema, pero

en principio se pueden definir nuestros propios tipos de datos (seran
tipos de datos no reconocibles) o restringir un tipo de datos a un
rango de un XMLS Datatype, por medio del axioma owl:DataRange,
colocando dentro una enumeracin con el constructor owl:oneOf.
El significado del axioma para una propiedad

owl:functionalProperty significa que una propiedad para un sujeto x
slo puede tener un objeto. Por tanto, Si tenemos en nuestra base de
103
conocimiento la asercin P(x,y) y adems la asercin P(x,y2),

entonces podremos concluir que y=y2 si P es funcional.
Tras estas ltimas aclaraciones ya hemos definido el lenguaje OWL, por lo

que a continuacin veremos un ejemplo en el que se ha utilizado este
lenguaje dentro de la web semntica.
3.3.5.4 Ejemplo de uso: OWL-S

OWL-S fue admitido en W3C en noviembre de 2004 como Draft Proposal.
El objetivo del lenguaje es permitir la definicin de ontologas que
proporcionen un modelo de servicio sin ambigedades[ZHO06]. Se inici
como DAML-S, luego pas a ser DAML+OIL-S [PAO03]. Actualmente ha
evolucionado hacia OWL-S [ANK04], siempre siguiendo las ltimas
mejoras en lenguajes ontolgicos par la Web. La ltima especificacin se
puede encontrar en [WWW14].
OWL-S pretende enriquecer los actuales servicios web (Web Services) con
informacin semntica. La infraestructura propuesta se puede ver en la
Figura 3.7.
DAML-S service
CAPA DE TRANSPORTE
DAML-S DAML-S
process model service profile
DAML-S grounding
XML
WDSL
SOAP
Figura 3.7. DAML-S Infraestructura
El concepto de Servicios Web se genera con la idea de crear una red en la

que los programas actan como agentes independientes que producen y
consumen informacin, automatizando procesos y realizando transacciones
104
B2B (business to business). La relacin entre esta idea y que exista un

lenguaje que permita transmitir cierta semntica a estos agentes es directa.
El sistema utiliza ya lenguajes existentes en la web. Se basa en XML/OWL,

y ha de comunicarse con WDSL (Web Services Description Language) En
la comunicacin OWL-WDSL se describe el interfaz del servicio a utiliza o
a ofrecer, a modo de descripcin de una API). Se utiliza tambin SOAP
(Simple Object Access Protocol), utilizado en la web para pasar mensajes
entre servicios web. WSDL y SOAP se basan a su vez sintcticamente en
XML.
La Ontologa propuesta en OWL-S para un servicio se basa en dividirlo en 3

conceptos:
Lo que necesita para ser invocado y qu devuelve. Este bloque es

el Service Profile. Es lo que utiliza para publicarse en la Web.
Informacin acerca del funcionamiento, qu modelo sigue. Este

bloque es el Service Model, y explica cmo funciona el servicio.
Esta informacin se suele usar para poder encadenar varios Servicios
y obtener un resultado al final de esa combinacin de servicios, o
para en un futuro poder monitorizar la ejecucin de un servicio.
Actualmente existen propuestas [ROU05] en las que se relaja esta
parte, permitiendo que no sea parte de OWL-DL, limitndola a
lgica de primer orden.
Informacin del modo de uso, es decir, cmo se relaciona con

WSDL y SOAP. Trata de los detalles de formatos de los mensajes,
nmeros de puertos, tcnicas de serializacin.
Es decir, El Servicio presenta (presents) un ServiceProfile, se describe por

medio de (describedBy) un ServiceModel y soporta (supports) un
ServiceGrounding.
Estos puntos son el inicio de una Ontologa, que podemos ver en el ejemplo
3.9:
<?xml version="1.0"?> [Ej. 3.9]

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-
syntax-ns#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
105
xmlns:rdfs="http://www.w3.org/2000/01/rdf-
schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns="http://www.owl-
ontologies.com/unnamed.owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:base="http://www.owl-
ontologies.com/unnamed.owl">
<owl:Ontology rdf:about=""/>
<owl:Class rdf:ID="ServiceProfile"/>
<owl:Class rdf:ID="ServiceGrounding"/>
<owl:Class rdf:ID="Service"/>
<owl:Class rdf:ID="ServiceModel"/>
<owl:ObjectProperty rdf:ID="describedBy">
<rdfs:domain rdf:resource="#Service"/>
<rdfs:range rdf:resource="#ServiceModel"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="supports">
<rdfs:range rdf:resource="#ServiceGrounding"/>
<owl:ObjectProperty rdf:ID="presents">
<rdfs:range rdf:resource="#ServiceProfile"/>
</rdf:RDF>
Pero la ontologa es ms amplia, ya que cada elemento tiene a su vez sus

propiedades:
ServiceProfile, tiene nombre (serviceName), informacin de

contacto (contactInformation) y descripcin (textDescription),
parmetros que pueden ser entradas (hasInput) o salidas
(hasOutput), precondiciones (hasPrecondition) y efectos (hasEffect),
un conjunto de parmetros del servicio (definidos por
serviceParameter y sParameter) y una categorizacin del servicio
(por medio de categoryName, taxonomy, value y code). Esto ltimo
nos permitir saber de qu tipo de servicio se trata (reserva de viajes,
compra de entradas de cine, etc).
ServiceModel, que describe los procesos por medio de la clase

Process, y su workflow entre los procesos si el servicio es una
106
composicin de procesos atmicos (por medio de lo que se llama

ControlConstruct). Cada proceso tiene entradas y salidas.
ServiceGrounding, que conecta con WDSL por medio de la clase

WDSLGrounding, que contiene la configuracin del WDSL (por
ejemplo, dice si el servicio realiza una operacin o devuelve un
documento).
3.3.6 SWRL
Semantic Web Rule Language (SWRL [SWRL04]), es otro lenguaje
desarrollado a partir de OWL ampliado con definicin de reglas al estilo de
RuleML. Las ampliaciones ms importantes son:
Definicin de variables que representan a instancias (individuals) o

a un valor de tipo de datos (datatype). Normalmente se representa
para que se entienda la notacin no SWRL como ?variable. Por
ejemplo, ?x:
<swrl:Variable rdf:ID="x"/> [Ej. 3.10]
Definicin de atom, como unidad mnima de significado para una

regla. Si x e y representan o una variable o una instancia
determinada o un valor de tipo de datos determinado, podemos decir
que un atom puede ser una definicin de clase, C(x), una propiedad,
P(x,y) o una asercin de igualdad, sameAs(x,y) , o desigualdad,
differentfrom(x,y).
Definicin de conjunto de atoms, por medio de <swrl:Atomlist>, a

modo de lista RDF.
Definicin de reglas, como un conjunto de atoms que generan el

antecedente (body) de la regla y otro conjunto de atoms que generan
el consecuente (head), que representa la siguiente regla:
antecedente con sec uente [Expr. 3.35]
Si actualmente las herramientas para OWL DL son muy limitadas, las pocas
herramientas para SWRL existentes se encuentran, como se indica en
[CRE05], an en un estado menos maduro y habiendo algunas variaciones
entre la sintctica y la sintaxis entre distintas versiones e implementaciones
107
de herramientas (aunque hay algn ejemplo terico de desarrollo como en

[GUE05]), por lo que su uso ha sido descartado para esta Tesis.
Tras haber revisado los lenguajes ontolgicos, sus posibilidades expresivas

y su complejidad de computacin, concluimos que el lenguaje ptimo
actualmente para desarrollar nuestra Tesis, siendo el ms utilizado en la web
semntica, es OWL, y en este caso especificaremos como ptimos el nivel
OWL DL, que conjunta una gran expresividad con una computacin costosa
pero posible.
108
Captulo 4. Primeras interacciones: Evaluaciones
Captulo 4: Primeras
interacciones:
Evaluaciones
4.1 Introduccin
En los captulos anteriores se ha realizado un estudio del estado del arte en
los mbitos que abarca esta Tesis, relativos a teleeducacin y web
semntica, que incluyen a su vez el estado de la web actual, las ontologas
de teleeducacin, los conceptos de lgica descriptica y de racioncinio, y por
ltimo los lenguajes ontolgicos actuales. A partir de este punto y a lo largo
de los restantes captulos se empezarn a describir los desarrollos y
resultados de esta Tesis.
Se comenzar en este captulo 4 por tratar los sistemas de evaluaciones y

ontologas relacionadas, tratando a fondo los estndares ms utilizados y
presentando una ontologa desarrollada (TeML) que contiene algunos
conceptos innovadores. Dichos conceptos, junto con las principales
aportaciones ontolgicas del estandar ms utilizado para la exportacin de
109
evaluaciones (IMS QTI) sern utilizados para una parte de la ontologa que
especificaremos en el captulo 6. En el captulo 5 se propondr una
arquitectura que permita las bsquedas semnticas en la web por parte de los
agentes inteligentes, as como el acceso a los objetos de aprendizaje. Por
tanto la arquitectura nos permitir explotar la ontologa desarrollada en esta
Tesis de una manera eficiente para la distribucin de contenidos educativos.
Por ltimo en el captulo 7 se realizar una prueba de concepto cuyos
resultados demuestren y validen el funcionamiento de distintas partes de la
arquitectura propuesta as como de la ontologa desarrollada en esta Tesis,
aportando adems resultados de eficiencia.
Una evaluacin es un conjunto ordenado de elementos (tems) que se usan

para evaluar los conocimientos de un candidato en un campo determinado
(outcomes). Dichos conocimientos pueden representar por ejemplo el nivel
de dominio de una materia. Una evaluacin contiene todas las instrucciones
necesarias para presentar correctamente los elementos y para realizar el
clculo de los valores de los resultados (por ejemplo, la nota final de un
test). Esta definicin est basada en IMS QTI[QTI06].
Despus de las interacciones bsicas de las pgina HTML (links), se puede

decir que las evaluaciones fueron el primer grupo de interacciones que
apareci en la Teleformacin, y hoy en da son las interacciones ms
comunes en un proceso de aprendizaje va web. Se fundamentan en la
existencia de un conjunto de preguntas o actividades sencillas que el
estudiante debe completar basndose en sus conocimientos, y normalmente
permiten una correccin automtica o semi-automtica de las mismas. El
resultado de esta correccin nos permitir evaluar si el alumno ha alcanzado
los objetivos de aprendizaje necesarios.
Las evaluaciones se desarrollaron con anterioridad a la aparicin de la

teleformacin, y vienen sobre todo aparejadas con cualquier formacin a
distancia, que es el caso en el que el tutor/docente tiene ms dificultad para
evaluar directamente y de forma continua al alumno.
El uso de los ordenadores para la evaluacin y autoevaluacin de los

estudiantes no es una novedad. Existen algunas aplicaciones desarrolladas
desde hace mucho tiempo como pueden ser TRIADS [MAC98], QUIZIT
[TIM97] [QUIT] o Questionmark [QMK06], y cada da aparecen
aplicaciones nuevas que se suman a la gran cantidad de aplicaciones
actuales. Adems, la mayora de plataformas de e-Learning ofrecen
servicios de creacin y uso de evaluaciones o tests, como ocurre en
110
WebCBT [WCT] (en 2006 absorbido por Blackboard [WWW72]), SAKAI,

.LRN y Moodle. Se pueden encontrar comparativas como en [GAM01]
[PAL99], o incluso realizar comparativas de las ltimas versiones de las
plataformas de e-Learning como Edutools [EDT].
Hoy en da las evaluaciones on-line han llegado a un nivel de madurez que

ha permitido desarrollar especificaciones muy completas como es el caso de
la especificacin IMS Question & Test Interoperability (QTI) V2 [QTI06].
4.2 Motivacin de las evaluaciones

El objetivo principal de los tests es evaluar de forma sencilla el progreso del
estudiante, tanto por parte de l mismo (autoevaluaciones) como por parte
de profesor. En el caso de que los evale el profesor, suele ser un inicio para
interactuar con el estudiante (va e-mail, chat o foro) y para orientar si es
necesario el proceso de aprendizaje.
Los beneficios que conlleva la introduccin de este servicio en nuestros
sistemas (tests on-line) de teleformacin son principalmente los siguientes
[KLEE98], [LLO96]:
La evaluacin on-line, en caso de poder ser corregida

automticamente, permite un rpido feed-back entre profesores y
estudiantes, para poder analizar los resultados y mejorar la
enseanza. Esto permite que tanto el profesor como el alumno (en
autoevaluaciones) se centren ms en los resultados y no en la parte
mecnica de correccin de exmenes.
El feed-back al contestar a un test o una pregunta del mismo puede

ser inmediato. Esto aporta grandes ventajas al proceso de
aprendizaje, ya que es en el momento que se contesta a un test
cuando ms inters se tiene sobre el mismo y permitir que el
alumno repase los conceptos que necesita en el momento.
Al poder manipular los datos de forma electrnica, podemos obtener

informaciones generales estadsticas tambin ms rpidamente y de
una forma ms flexible, permitiendo, por ejemplo, evaluar la
dificultad de una pregunta o localizar preguntas que necesitan una
modificacin en su formulacin.
Permite la inclusin de contenidos multimedia, lo que es una mejora

respecto a las evaluaciones en papel.
111
Permite presentar exmenes diferentes para cada alumno, segn

algn algoritmo (que normalmente es obtener las preguntas
aleatoriamente de un superconjunto de las mismas). Dicho algoritmo
puede basarse en datos del alumno en cuestin, generando un
examen personalizado a las caractersticas de cada alumno.
Permite asignar metadatos a las preguntas, exmenes, contestaciones

y otros objetos lgicos de un test. Estos metadatos pueden
almacenarse en lenguajes propietarios y dependientes de la
aplicacin o pueden ser metadatos en lenguajes estndar o siguiendo
ciertas recomendaciones en el campo.
Permite correcciones masivas de exmenes, si la correccin se puede

automatizar. Esto permite la realizacin de exmenes masivos y
ofrecer los resultados de los mismos en un tiempo razonable, como
se ha hecho con los test de sistemas de lectura ptica.
Permiten medir el progreso realizado tras una experiencia educativa,

por medio de una evaluacin antes de la experiencia y otra despus.
Permiten medir los conocimientos iniciales de un alumno antes de

comenzar la experiencia educativa, para evaluar si cumple los
requisitos o se necesita algn material de apoyo para nivelarse.
Como podemos apreciar, obtenemos ventajas debido al tratamiento y

almacenaje automtico de las evaluaciones, como son el rpido feed-back,
ya sea porque la realimentacin es automtica o porque la rpida correccin
del examen permite saber la nota al alumno y al profesor, y reaccionar al
respecto. Esta facilidad de tratamiento permite tambin realizaciones y
correcciones de exmenes de forma masiva, ya que no requieren gran carga
computacional en los servidores. Adems, la facilidad de acceso y
tratamiento a los datos almacenados permite, respecto a las preguntas,
preparar exmenes personalizados y distintos a cada alumno, generando
incluso evaluaciones de acceso para evaluar el nivel de conocimiento inicial.
Respecto a las contestaciones, la facilidad de acceso y tratamiento permite
realizar dataminig sobre las mismas para extraer informacin estadstica que
nos permita obtener conclusiones.
Pero el punto que ms nos interesa en la Tesis es la asignacin de metadatos

a los distintos elementos que participan en una evaluacin, de modo que
podamos marcar y luego buscar elementos con unas caractersticas que haya
112
definido. Si los metadatos incluyen informacin ontolgica, como puede

realizarse con OWL, dicha informacin permitir a los agentes realizar
inferencias que permitan realizar bsquedas ms sofisticadas. Por ejemplo,
supongamos que un conjunto de exmenes, sobre la misma materia, tienen
una dificultad con un valor 7 sobre 10 (suponiendo que definimos en
nuestro sistema dificultades con valores entre 0 y 10). Si mi agente ha de
generar un examen de dificultad 4 sobre 10, puede tener definido que todos
los exmenes con todas las preguntas de dificultad X sobre 10 son exmenes
con dificultad X sobre 10. Entonces escogera las preguntas de mis
exmenes iniciales que tuvieran la dificultad que deseamos y los juntara en
un nuevo examen de la dificultad esperada.
4.3 Limitaciones de la Evaluaciones

Una de las mayores limitaciones de toda evaluacin a distancia es el control
que puede llevarse a cabo del estudiante durante la misma. La propia
libertad que nos ofrece la web, que en muchas ocasiones es una ventaja, nos
permite realizar las operaciones desde cualquier lugar y en cualquier
momento. En evaluaciones este aspecto puede ser contraproducente ya que
es muy difcil comprobar que el alumno realiza la prueba en las condiciones
exigidas.
En una evaluacin presencial, los alumnos se encuentran ubicados en

recintos definidos, de forma que se pueden utilizar mecanismos de
vigilancia y control para que la prueba se realice cumpliendo con ciertos
requerimientos. En el caso de las evaluaciones on line la vigilancia y el
control son difciles de llevar a cabo, de forma que nos encontramos con los
siguientes riegos:
Suplantaciones. En este caso es otro individuo distinto al estudiante

evaluado el que realiza la prueba, y este hecho es ocultado a los
evaluadores.
Uso de ayudas externas. Como por ejemplo el uso o consulta de

material no permitido durante la evaluacin.
Colaboracin con otras personas. En esta situacin el alumno

evaluado es el que realiza la prueba, pero recibe ayuda externa de
otras personas que no estn siendo evaluadas, lo cual falsea el
resultado.
113
Actualmente, en las evaluaciones que se realizan va web, para resolver este

inconveniente se recurre a soluciones del tipo que presentamos a
continuacin:
Confiar en la buena voluntad del estudiante. Un estudiante

debidamente motivado no debera perder la oportunidad de
comprobar los conocimientos adquiridos.
No dar una gran importancia a las evaluaciones ms que para

informacin del alumno. De este modo no existe mvil para recurrir
a algn tipo de manipulacin de las mismas.
Recurrir a pruebas vigiladas (por ejemplo, realizadas en aulas de

academias acreditadas). Se puede incluso realizar vigilancias a
distancia por medio de webcams y Netmeeting, por ejemplo. El uso
de aulas acadmicas con ordenadores para todos los exmenes
genera problemas logsticos como los planteados en [HOL04].
Otro problema muy comn en las evaluaciones va web se presenta en los

sistemas en los que se decide que la computacin de la respuesta correcta se
haga en el ordenador del alumno, por tanto la informacin sobre cmo se va
a corregir se enva al alumno con una cierta encriptacin u ocultacin. Este
es un problema del que adolece SCORM, donde se define que el SCO
procesa (con javascript) si los objetivos de aprendizaje se han cumplido o
no[ADL04b].
La solucin para este problema es, adems de las anteriores planteadas para
el caso de evitar fraudes, que no se enve ninguna informacin sobre el
proceso de clculo de los resultados de una evaluacin al ordenador del
cliente, o que se enve al computador del alumno un valor encriptado por
respuesta, que slo el servidor pueda decodificar y entender si es una
respuesta correcta o incorrecta[ROM06].
Y una ltima dificultad, que supone un riesgo principalmente en

evaluaciones oficiales, es el poder verificar que las respuestas obtenidas en
la prueba fueron las que efectivamente contest el alumno y que no ha
surgido un problema en el sistema que haya podido modificarlas.
Este problema no se presenta en las evaluaciones presenciales, ya que

cuando se valora un documento escrito por el alumno, el propio manuscrito
constituye una prueba de su autenticidad.
114
En el caso de las evaluaciones on line, incluso aunque se utilice algn

mecanismo de seguridad como la firma digital del alumno para verificar el
envo, no existe una prueba fehaciente de la autenticidad de las respuestas,
ya que el alumno podra argumentar que hizo el examen (hecho que probara
la firma digital) pero que esas no fueron sus respuesta, lo que planteara la
posibilidad de un fallo en el sistema..
Para resolver este problema se plantean dos posibles soluciones:
Cuando la evaluacin del alumno tiene lugar en las dependencias de

la entidad examinadora, se puede obtener una copia impresa de su
examen, que el alumno firma y entrega. Este documento nos servir
como prueba en el caso hipottico de que el alumno planteara alguna
duda sobre la autenticidad de la evaluacin electrnica que ha
realizado.
Independientemente del lugar donde tenga lugar la evaluacin del

alumno, se le puede facilitar un documento electrnico con sus
respuestas, visado mediante firma digital por la entidad examinadora.
Si el alumno no muestra disconformidad, este documento tambin
servir como prueba en el caso hipottico de que se planteara alguna
duda sobre la autenticidad de la evaluacin electrnica realizada.
Por tanto, la mayora de las limitaciones de las evaluaciones en la

teleformacin parten de la dificultad de asegurar la autora y las condiciones
ambientales en el momento de la realizacin de las contestaciones, tanto por
parte de la entidad, como por parte del mismo interesado a la hora de
reconocer el resultado de las mismas. La autora se puede subsanar por
medio de un sistema de firmas digitales, pero el aseguramiento de las
condiciones de contorno en el momento de contestacin del mismo es un
punto an por resolver si deseamos libertad en el emplazamiento del
alumno.
4.4 Metadatos y Ontologas en las evaluaciones

Uno de los puntos clave para el futuro desarrollo de la web semntica es la
incorporacin de metadatos a los objetos utilizados, de modo que los
agentes inteligentes puedan procesarlos y entenderlos para poder realizar
inferencias sobre los mismos. De hecho, mientras para los usuarios finales el
contenido del texto de una pregunta es la informacin con la que trata, para
los agentes que encuentren esta pregunta puede que les sea ms til conocer
115
la temtica de la pregunta, las posibles respuestas a presentar y el autor. Los

agentes no podrn realizar funciones ms avanzadas que presentar un texto
obtenido mediante un identificador sin la existencia de metadatos que nos
indiquen detalles de las evaluaciones con las que tratemos, as como sin una
ontologa implcita para agentes de uso especializado o explcita para
agentes ms generalistas. Los metadatos permiten de esta forma facilitar la
interoperabilidad de dichas evaluaciones, tanto a nivel del tests como a nivel
de preguntas individuales, de modo que podamos exportar cursos completos
con sus evaluaciones o montar un curso reusando evaluaciones y preguntas
de repositorios heterogneos.
Como ya hemos comentado, actualmente hay una gran gama de soluciones

que cubren las evaluaciones on-line, cada una con su propia definicin y
ontologa implcita. Pese a la gran variedad de soluciones similares e
incompatibles entre s, la incorporacin de metadatos tiene lugar en pocas
ocasiones, con definiciones propietarias de los mismos y con un nico
estndar de intercambio limitado como es IMS QTI (basado en
XML/XHTML/XMLS).
En este apartado haremos una breve descripcin de IMSQTI y sus

metadados relacionados, as como sobre la implementacin de un modelo
completo de evaluaciones va web, desarrollado en el Departamento de
Comunicaciones, y que permite ampliar y comparar el espectro de
informacin disponible en los metadatos de IMSQTI.
4.4.1 IMS QTI

La especificacin de IMS sobre Question & Test Interoperability (QTI)
describe un modelo para la representacin de preguntas (AssessmentITem),
tests (AssessmentTest) y sus correspondientes resultados.Esta especificacin
pretende el intercambio de preguntas, tests y resultados de los tests entre
herramientas de autor, pools de contenidos educativos, herramientas de
explotacin de tests y herramientas de explotacin de recursos educativos
(LMS). La especificacin se basa en un modelo de datos descrito en UML y
con una traslacin directa a XML para su intercambio[IMS06].
La especificacin comenz en sus primeras versiones en 1999,

incorporndose a la especificacin de la estructura abstracta de
IMS[IMS03b]. En 2006 se publica la versin 2.1 de la especificacin, en la
que incluye ya el concepto de tests y de presentacin de los resultados, con
la posibilidad de relacionar preguntas por medio de secciones y reglas.
116
4.4.1.1 Elementos principales de IMS QTI

Los elementos principales de la especificacin se basan en el estudio de la
gran mayora de sistemas de exmenes on-line, de forma que cubra de forma
general la mayora de los sistemas y por tanto cualquier sistema pueda
exportarse. Tambin intenta resumir los conceptos principales, actores y
funcionamiento general de un sistema de evaluacin. La especificacin se
basan en la definicin de unos conceptos (que nosotros asimilaremos a
clases) relacionados entre s, as como la definicin de un comportamiento
determinado y una representacin de esas clases y relaciones en
XML[QTI06b].
Los conceptos principales son los de la pregunta en s, con sus

componentes, la agrupacin de preguntas para componer una evaluacin
determinada y la agrupacin de preguntas a nivel de repositorio de las
mismas. Tambin abstrae el concepto de respuesta de un alumno, as como
el tratamiento de la misma para evaluar al alumno. Su estructura se puede
describir de la siguiente forma (Fig. 4.1):
Fig. 4.1. Estructura IMS QTI
La base principal es la pregunta (clase assessmentItem), considerada como

la unidad indivisible a la hora del intercambio de contenidos. Es el
equivalente intuitivo de una pregunta de un test. Puede ser Sencilla o
Compuesta (conjunto de preguntas sencillas que comparten alguna parte).
Para su intercambio se agrupan en Pools o repositorios (clase pool) de
preguntas.
Luego tenemos la Evaluacin (clase assessmentTest), que representa a un

conjunto de preguntas que se configuran para ser respondidos por un
estudiante. Pueden relacionrsele resultados globales y notas globales.
La pregunta contiene los siguientes datos:
117
Cuerpo de la pregunta (Texto o imgenes), definido dentro del

elemento itemBody que indica a su vez los recursos que necesita
(imgenes, textos, html, etc). Para la presentacin de la pregunta se
permite la utilizacin de hojas de estilo y en el texto se permite
cierto XHTML (eXtended HTML) para subrayados, negritas,
elementos para interactuar, etc., as como MATHML. Dentro del
cuerpo de la pregunta se incluye a su vez una descripcin de las
posibles interacciones que puede realizar el usuario sobre la
pregunta. Ms adelante se describir con ms detalle el concepto de
interaccin.
Informacin de cmo se ha de procesar la respuesta, de forma

que cuando se conteste a una pregunta, por medio de unas reglas
definidas en ese punto, se obtenga el resultado de la evaluacin de
conocimientos (representado en la clase outcome) a travs de un
conjunto de variables de resultado. Normalmente dichas variables
son numricas y se suelen ponderar luego a la hora de evaluar un test
en conjunto.
La pregunta puede contener tambin un posible feedback para el

alumno, representada en la clase feedback. La clase feedback incluye
informacin tambin de en qu casos se ha de presentar al alumno.
Se distingue entre el feedback modal y el incrustado. El modal se
presenta al alumno cuando ya se ha procesado la respuesta a la
pregunta y tenemos el resultado, de modo que la interaccin se ha
terminado, pues se basa en el resultado obtenido. Por otro lado
tenemos el feedback incrustado (definido por la propiedad inline),
que se asocia a una respuesta del usuario, antes de procesar dicha
respuesta. Por ejemplo, un feedback modal podra decir qu repasar
si no has acertado y uno inline te explicara por qu la respuesta que
has dado en particular es incorrecta.
La especificacin permite tambin la posibilidad de que un test o un tem

sean adaptativos, es decir que varen segn los resultados de los usuarios.
Por ejemplo, un test que cuando se contesta de forma errnea a una pregunta
bsica de un tema ya no sigue preguntando sobre ese tema o una pregunta
compuesta que segn lo que se haya contestado pida alguna aclaracin.
4.4.1.2 Interacciones en IMS QTI

IMS define respuesta como el dato que nos indica el usuario por medio de
su interaccin con la pregunta. Esta interaccin ser la base para poder
118
describir cmo han de comportarse las preguntas tras una contestacin.. Las
respuestas pueden tener un conjunto de variables de respuesta
(representadas en la clase responseVariable) que sern tratadas en el
procesamiento de la respuesta.
Para hablar del comportamiento de las preguntas en tiempo de ejecucin, es

necesario definir el concepto de Sesin de usuario, como el contexto en el
que tienen sentido las variables de las que hablamos y en el que el estudiante
realiza sus interacciones. Cada vez que un usuario interacta con las
preguntas, se genera un conjunto de variables que son especficas de un
periodo de interaccin usuario-sistema. El conjunto de esas variables
definen la Sesin de usuario, y nos constituyen el sistema de memoria de las
relaciones desarrolladas durante ese periodo de tiempo.
El comportamiento principal es el siguiente (Fig. 4.2 ):
INTERACCIN
RESPONSES
PROCESAR
RESPUESTA
OUTCOMES
HAY FEEDBACK SI FEEDBACK

MODAL?
NO
FIN
Fig. 4.2. Comportamiento en IMS QTI
119
1. Al alumno se le presenta la pregunta, e interacta con ella

dependiendo del tipo de pregunta. Como ejemplo de interacciones
tenemos la eleccin de una de las respuestas si es una pregunta de
opciones simple, o la eleccin de varias si es mltiple. Otra posible
interaccin sera la escritura de cierto texto, o el desplazamiento de
un objeto grfico a un punto determinado.
2. Las interacciones son convertidas por el sistema en respuestas. Por

ejemplo, en una pregunta de opciones simple, se define una variable
de respuesta como un valor nico que se le asignar el identificador
de la opcin de respuesta seleccionada.
3. Al obtener las variables de respuesta arranca el procesado de las

mismas. Para realizar dicho procesamiento se utilizan las reglas
definidas( que vendrn descritas en las instancias de la clase Rule),
que normalmente son condicionales (descrita por medio de
instancias de las sublases responseIf , responseElseIf y responseElse,
aunque existen otras subclases posibles) y expresiones de esas
condicionales. Un ejemplo de regla que se puede describir es Si la
respuesta coincide con la respuesta correcta, coloca un 1 en la
variable de resultado denominada NOTA, si no asignale 0. Puede
que ocurra que existan feedbacks definidos, que se ofrecern al
alumno durante el procesamiento si son incrustados.
4. Tras procesar las respuestas, el sistema obtiene las variables de

resultado, que pueden conducir a feedbacks modales si existen. Si no
es as, se reporta el resultado obtenido al sistema y, resetea las
variables de respuesta y se espera a siguientes interacciones.
Por tanto el comportamiento en tiempo de ejecucin tras una interaccin de

un usuario en la realizacin de una evaluacin consiste en convertir esa
interaccin en variables de la sesin, procesar dichas variables en funcin de
sus reglas definidas y obtener variables de resultado, pudiendo presentar
alguna realimentacin en caso de estar definida.
En caso de preguntas condicionales, las variables de resultado no se borran

entre una interaccin y otra, ya que esta informacin puede afectar a
preguntas futuras. Adems, en las preguntas condicionales, la contestacin a
una pregunta puede provocar algn cambio en la presentacin de preguntas
de test, ampliando o reduciendo la cantidad de preguntas pendientes.
120
4.4.1.3 Empaquetado en IMS QTI

La especificacin indica cmo se han de agrupar los conjuntos de preguntas
o exmenes de forma que puedan ser exportados. Bsicamente sigue la
filosofa de IMS Content Packaging (CP) que se basa en un archivo
comprimido que contiene:
Las preguntas en s ,los tests y las estadsticas de uso de un test de

o un conjunto de preguntas . Los tests se representan mediante la
clase assessmentTest, donde se ofrece la informacin necesaria para
poder presentar y ejecutar un test completo. Los valores estadsticos
se agrupan en la clase bankProfile, que contiene elementos de la
clase usageData para cada grupo de estadsticas obtenidas en un
contexto determinado . Este conjunto se agrupa como uno o varios
archivos XML).
Los archivos de imgenes y extras necesarios. Estos archivos

estarn referenciados en los distintos cuerpos de las preguntas,
dentro del XHTML de las mismas. Mediante estos archivos
podremos introducir elementos multimedia dentro de las preguntas.
El manifiesto resumen del paquete, a modo de archivo XML

denominado imsmanifest.xml). Es aqu donde se almacena la
metainformacin sobre la posible estructura de las preguntas (en
tests), as como informacin ms general sobre las preguntas, los
exmenes y sobre el paquete en s.
En caso de agrupar no slo preguntas sino una unidad de aprendizaje, se

recomienda el uso del resto de especificaciones de IMS: IMS Learning
Design (LD, para la definicin de unidades de aprendizaje y para definir
reglas de paso de objetivos), IMS Simple Secuencing SS (para indicar la
estructura y navegabilidad del curso) y IMS CMI (para indicar la
comunicacin en tiempo de ejecucin de variables entre el cliente y el
servidor).
4.4.1.4 Metadatos en IMS QTI

IMS QTI permite aadir metainformacin en el momento de empaquetar un
conjunto de preguntas y/o exmenes, as como indicar el modo de
comportamiento y los elementos que componen el conjunto empaquetado.
Esto se hace por medio del manifiesto (imsmanifest.xml), como ya
adelantamos en el apartado anterior.
121
Un hito importante en la definicin de los metadatos fue la aparicin de la

versin 2.0 de IMS QTI. A partir de esta versin se lleg a un acuerdo para
utilizar IEEE LOM 1484.12.1-2002 (en particular su representacin en
XML) como base para describir los recursos educativos en el manifiesto,
ampliando alguno de los apartados y recomendando algunos valores
determinado para algunos de los apartados de IEEE LOM
El archivo resumen donde se encuentra la metainformacin en los paquetes

de IMS QTI, que como vimos anteriormente denominaremos manifiesto,
contiene en lneas generales (Fig 4.3 ):
Metainformacin sobre el paquete en s, situado entre las marcas

<cp:metadata>). Este apartado suele llevar la informacin sobre la
versin del IMS CP ( definido en <cp:schema> y
<cp:schemaversion>), y una descripcin del paquete en general
como recurso educativo en conjunto, usando IEEE LOM (por medio
de la marca <imsmd:lom>).
Descripcin de la organizacin del paquete , utilizando la marca

<cp:organization>. En este punto se suele colocar la informacin de
IMS LD [CAE05] si es necesaria. En la mayora de los casos,
cuando se trata de la agrupacin de un conjunto de preguntas sin
estructura educativa, la marca existe pero no contiene ningn
elemento.
Descripcin de los recursos unitarios que hay dentro del paquete,

que en este caso sern principalmente las preguntas. La descripcin
de los recursos unitarios se realiza dentro de la marca
<cp:resources>. Adems, por cada recurso habr una etiqueta
<cp:resource>.
122
Fig. 4.3. Descripcin general del manifiesto
En cada uno de las marcas cp:resource se describen los recursos que se

incluyen en el paquete: las preguntas, los tests, los resultados estadsticos y
los ficheros auxiliares que se comparten entre varias preguntas. A partir de
este punto nos centraremos en el elemento que describe cada uno de los
recursos, describiendo primero sus atributos y a continuacin los elementos
que contiene.
Los atributos de los recursos incluidos dentro de la marca <cp:resource>

son los siguientes:
Atributo de identificacin, denominado identifier, que contiene el

identificador nico del recurso. Este identificador ha de ser nico
obligatoriamente dentro del contexto del manifiesto, de forma que en
todo el manifiesto nos podamos referir al recurso con ese
identificador.
Atributo de localizacin fsica, denominado href, que indica la

ubicacin fsica del recurso (URL), siendo la ruta relativa dentro del
paquete. Este apartado ser utilizado a la hora de desplegar el
paquete en algn sistema de aprendizaje va web.
Atributo de descripcin del tipo de recurso, denominado type, que

nos describe del tipo de recurso. Por ejemplo, las preguntas de IMS
QTI versin 2.0 son del tipo imsqti_item_xmlv2p0. Este atributo slo
indica que el elemento es uno de los descritos en IMS QTI, sin llegar
a describir si es una pregunta, un test u otro elemento.
Podemos ver en el ejemplo 4.1, que indica un elemento con identificador

ID-23435632456ac3, siendo dicho elemento uno de los definidos en la
especificacin IMS QTI 2.0 y que est ubicada en el fichero pregunta.xml.
<manifest [Ej. 4.1]

xmlns:cp="http://www.imsglobal.org/xsd/imscp_v1p1">
<cp:metadata/>
<cp:organizations/>
<cp:resources>
<cp:resource identifier="ID-23435632456ac3"
type="imsqti_item_xmlv2p0" href="pregunta.xml">
.....
</cp:resource>
</cp:resources>
123
</manifest>
Dentro del manifiesto, los elementos principales que contiene cada uno de
los recursos son (Fig. 4.4):
Elemento de localizacin de ficheros, denominado <cp:file>,

elemento que indica la direccin de cada uno de los ficheros que
necesita: el mismo recurso en s. Por tanto habr un elemento de este
tipo para el fichero xml de la pregunta, y uno por cada uno de los
ficheros auxiliares (imgenes, etc). Esto permitir desagregar el
paquete de contenidos para separar cada uno de los recursos.
Elemento de metadatos del recurso , por medio de la marca

<cp:metadata>, donde se describe el recurso unitario. Para realizar
esta funcin utiliza de nuevo los elementos <cp:schema> y
<cp:schemaversion>, siendo en este caso su valor la descripcin de
la versin de IMS QTI utilizada. Tambin se incluyen el elemento de
IEEE LOM <imsmd:lom> y una extensin de IEEE LOM dentro del
recurso, denominada <imsqti:qtiMetadata>y que incluye la
metainformacin especfica de las preguntas que no est
contemplada en la versin de IEEE.
Fig. 4.4. Elementos principales de cp:resource
En el elemento de metadatos de las preguntas encontramos las

peculiaridades de las mismas. Para poder describir de forma completa a las
preguntas, en IMS QTI se ha optado por extender la ontologa de IEEE
LOM, tanto extendiendo elementos dentro de la especificacin IEEE LOM
124
como colocando otro elemento fuera de IEEE LOM de descripcin de

ontologa denominado imsqti:qtiMetadata, como podemos apreciar en la
figura 4.4.
Dentro de la ontologa definida por medio de IEEE LOM, la extensin ms

destacable es la inclusin de nuevos valores para el elemento kind de la
categora <relation>. Los nuevos elementos permiten indicar qu preguntas
excluyen a otras, por medio de la marca <precludes> y qu preguntas
necesitan de preguntas anteriores, por medio de la marca <requires>.
Tambin existe un elemento que permite indicar qu preguntas estn
agrupadas en secciones dentro de un test, mediante el uso de la marca
<issetmemberof>.
La extensin externa a la ontologa definida en IEEE LOM nos permitir

incluir informacin especfica de los elementos de una evaluacin. Como se
ha indicado anteriormente se realiza por medio del elemento
<imsqti:qtiMetadata>. Este elemento permite:
Definir el tipo de interaccin, con lo que indicaremos el tipo de

pregunta que es. Cada tipo de interaccin define unos parmetros
diferentes en el archivo .xml especfico de la pregunta, de modo que
en el momento de realizacin de un test el sistema ha de presentar la
pregunta de una forma determinada para que cumpla sus objetivos.
El tipo de pregunta tambin condicionar el tipo de respuesta que se
puede presentar, que podr representarse en una o varias variables de
tipo identificador, parejas de identificadores, numrico, textual, de
localizacin de un fichero, etc) Los tipos posibles son:
- choiceInteraction, cuando es una pegunta en la que se selecciona

entre un grupo de posibles respuestas.
- inlineChoiceInteraction, parecida a choiceInteraction pero las

opciones las presenta incrustadas dentro de un texto.
- gapMatchInteraction, donde hay un texto con huecos y un

conjunto de palabras que se pueden utilizar.
- associateInteraction, cuando hay que asociar por parejas

elementos (normalmente textos).
125
- textEntryInteraction, usado para rellenar huecos de texto

pequeos. Normalmente se usa para preguntas de tipo rellena
los huecos.
- extendedTextInteraction, donde el alumno rellena un texto a

enviar, de cierta longitud (por ejemplo, si se pide escribir una
redaccin sobre algo).
- hottextInteraction, donde el alumno ha de elegir si marca o no un

conjunto de frases o partes de frases definidas como marcables.
Un ejemplo es cuando tenemos un texto y hay una partes
subrayadas que hemos de decir si son correctas o no.
- matchInteraction, donde se relacionan los elementos por parejas.

La diferencia con associateInteraction es que en este caso se
define un conjunto de elementos origen y un conjunto de
elementos destino, y se empareja siempre un origen con un
destino. En el otro caso no se distingue entre elementos de un
tipo o de otro.
- orderInteraction, donde el alumno ordena un conjunto de

elementos.
- graphicAssociateInteraction, como cuando asociamos nombres

pero asociamos regiones de una imagen con otras, dos a dos. (por
ejemplo, para un ejercicio de unir los puntos).
- drawingInteraction, pregunta en la que se ha de dibujar algo. El

sistema presenta una imagen inicial (puede ser un lienzo en
blanco) y el sistema ha de presentar mecanismos para que el
alumno pueda dibujar y enviar el fichero de resultado para ser
corregido.
- graphicGapMatchInteraction, cuando el alumno ha de arrastrar

imgenes pequeas dentro de una imagen grande, y hay una zona
sobre la que ha de soltar esa imagen para que se considere la
respuesta como correcta.
- graphicOrderInteraction: donde se han de ordenar correctamente

un grupo de regiones de una imagen.
126
- hotspotInteraction, donde el alumno ha de elegir qu regin de

una imagen pulsar dentro de un conjunto definido de regiones.
Por ejemplo, un dibujo con un perro y un gato, con una regin
que delimita el perro y otra al gato y se pide que seale al perro.
- positionObjectInteraction, donde hay unas imgenes que hemos

de colocar dentro de otra imagen de fondo en su posicin
correcta. Por ejemplo, situar la silueta de un pas europeo en su
posicin correcta dentro de Europa.
- selectPointInteraction, donde el alumno marca un punto de una

imagen, y dependiendo de la coordenada se da una puntuacin.
En este caso se definen reas de la imagen con una puntuacin,
para que no haya que marcar el punto exacto al pixel.
- sliderInteraction, donde al alumno elige un valor por medio de

desplazar un puntero a lo largo de una barra de desplazamiento.
Suele utilizarse para poder dar valores aproximados.
- uploadInteraction, en el que el alumno carga un fichero al

sistema como resultado.
- customInteraction, que se utiliza para extensiones de sistemas

que tienen tipos de preguntas no representables con el conjunto
anterior,
- endAttemptInteraction, es una interaccin auxiliar que se usa

cuando el alumno desea terminar de probar una pregunta (por
ejemplo, si se rinde y no sabe la respuesta).
Definir si el recurso es dependiente del tiempo , por ejemplo, si

para una pregunta hay un lmite temporal desde su presentacin al
alumno hasta la obtencin de la respuesta. Esta definicin se hace
por medio de la marca <TimeDependent>.
Definir si la respuesta correcta est incluida en la definicin de

la pregunta, por medio de la marca <solutionAvailable>. Las
preguntas que no la tengan incluida exigirn un tratamiento manual
de correccin.
127
Definir si tiene feedback y si la pregunta es adaptativa o no, por

medio de <feedbacktype>. Una pregunta adaptativa es la que cambia
su representacin en funcin de la interaccin del usuario.
Definicin de templates. La utilidad de los templates surge cuando

vamos a hacer un conjunto de preguntas en las que hay partes, como
la gestin de la respuesta, que son exactamente iguales, por lo que se
colocan en un fichero separado. Se indica mediante la marca
<itemTemplate>si el recurso es un template o no.
Indicacin de si el elemento es compuesto o simple. Si el elemento

es una composicin de interacciones se indica por medio de la marca
<composite>.
Informacin sobre la herramienta de autor con la que se ha

generado la pregunta, por medio de las marcas
<toolname>,<toolversion> y <toolvendor>.
Toda esta informacin introducida en el elemento imsqti:qtiMetadata podra

inferirse por medio de una introspeccin de los distintos ficheros XML de
las preguntas, por lo que se podra considerar que la informacin est
repetida en el manifiesto y en los elementos en s.. Sin embargo, esto
permite separar lo que se considera como metadatos en IMS QTI de los
ficheros de las preguntan, permitiendo que el manifiesto sea susceptible de
ser publicado para describir las preguntas, sin tener que publicar el detalle
de las preguntas.
Otro punto donde se pueden definir metadatos es en los recursos que

describen estadsticas de exmenes o preguntas. En ellos se describe el
contexto de la estadstica -nmero de muestras, fechas de realizacin,...- el
tipo de estadstica realizada -por medio de una catalogacin de estadsticas
no definido an en la especificacin- y el valor de la estadstica, con valores
de las desviaciones si se desea. IMS QTI recomienda indicar en los valores
estadsticos la media del resultado obtenido por cada pregunta, aunque se
permite en su lugar colocar el porcentaje de gente que ha contestado a una
respuesta determinada.
4.4.2 TeML: Ontologa basada en XML para evaluaciones

En este apartado describiremos una ontologa de descripcin de las
evaluaciones en Teleformacin desarrollada en el Departamento de
Comunicaciones de la Universidad Politcnica de Valencia. Esta ontologa y
128
su implementacin del modelo ontolgico se termin en el ao 2002, siendo

su mayor novedad el uso de XML como lenguaje para almacenar las
evaluaciones, as como su desarrollo totalmente por web, sin ningn tipo de
aplicacin local. Se puede ampliar la informacin en [MAN02], [MAN02B]
y [PAL03].
4.4.2.1 Elementos principales de la ontologa

La ontologa est enfocada alrededor del concepto Pregunta, de modo que
un autor introduce peguntas que luego utiliza para definir exmenes. Las
preguntas tratan de ciertos Conceptos, y esos conceptos pertenecen a una
Asignatura. Las asignaturas tratan de ms de un concepto, como veremos
ms adelante.
Los estudiantes se consideran estudiantes de una Asignatura, por lo que

podemos asimilar Asignatura por Curso como se entiende en
Teleformacin, y los profesores podan serlo de varias asignaturas. De esta
forma definimos propiedades de objeto que relacionan a un estudiante con
una o varias asignaturas, y propiedades de objeto que relacionan un profesor
con una o varias asignaturas.
Los estudiantes obtienen, a partir de las evaluaciones, notas sobre cada

examen, y un informe de los conceptos que hayan acertado. Podemos
considerar que generamos una propiedad de tipo de datos que relaciona una
contestacin al examen con una nota, y un conjunto de relaciones de objeto
que relaciona la contestacin al examen con un conjunto de conceptos que el
alumno ha demostrado dominar por medio de la contestacin del examen.
La ontologa no se desarroll por medio de lenguajes ontolgicos, ya que en

2001/2002 utilizar XML ya se puede considerar como un avance
considerable, aunque s que existe una ontologa implcita como podemos
apreciar en la figura 4.5, donde vemos parte de la misma.
129
Fig. 4.5. Resumen de la ontologa implcita
El funcionamiento del sistema consiste en lo siguiente:
El Profesor crea preguntas en el sistema, indicando el enunciado y

las posibles respuestas, marcando las respuestas correctas. Tanto el
enunciado como las respuestas pueden tener un fichero multimedia
asociado, bien sea una imagen, un sonido, un video, u otro formato
visualizable con un navegador. Se definen tipos de preguntas segn
los ficheros multimedia que contengan, para facilitar la introduccin
y previsualizacin de los mismos.
El Profesor define un Examen y lo relaciona a un conjunto de

preguntas. En el proceso de generacin de un Examen, se define la
dificultad del mismo por medio de unos valores de dificultad
mxima y mnima, que nos indicarn los lmites de dificultad de las
preguntas escogidas. Adems se define la cantidad de preguntas y el
nmero de respuestas mnimo que tiene que tener cada pregunta. De
esta forma el sistema, a modo de agente, le presenta un pool de
posibles preguntas que cumplen esos requisitos y el profesor escoge
las que desea utilizar. Tambin se define en el proceso si el examen
se puede corregir de forma automtica, de forma que slo contiene
130
preguntas cuyo proceso de correccin no precisa de una intervencin

humana.
Cuando el profesor termina de definir el examen, se almacenar en el

sistema junto con una descripcin XML del mismo y una versin de
presentacin por defecto del mismo en JSP. De esta forma podemos
considerar que tenemos una metainformacin del examen en el
archivo XML y una localizacin del recurso listo para ser presentado
al alumno, a modo de archivo JSP.
El Alumno contesta al examen, y si el examen est definido como

examen que permite autocorreccin directa, presenta la nota. Existen
casos en los que, aunque el sistema pueda corregir automticamente,
se considera ms adecuada una revisin por el profesor, de forma
que pueda modificar la nota segn algn criterio determinado, como
puede ser la evolucin e inters del alumno a lo largo del proceso de
aprendizaje. Por esta razn se debe indicar explcitamente si el
sistema debe presentar directamente al alumno al nota. La
contestacin del alumno se almacena junto con una descripcin
XML de dicha contestacin al examen. De esta forma el objeto de
contestacin al examen se almacena a modo de metadatos en el
fichero XML.
El profesor, tras la realizacin de un examen puede ver las

contestaciones de los alumnos, modificarles las notas, modificar la
dificultad de las preguntas o lanzar un proceso de reclculo de la
dificultad de la pregunta. Trataremos este tema ms adelante.
4.4.2.2 Clasificacin pedaggica

La clasificacin pedaggica utilizada en el sistema est orientada a su uso
dentro de la Universidad, por lo que habla de Asignaturas, Preguntas y
Conceptos.
Una instancia de la clase Asignatura puede tener n Conceptos, y cada

Concepto puede pertenecer a m Preguntas. De esta forma hay una propiedad
de clase que relaciona una instancia de Asignatura con una instancia de
Concepto, y dicha propiedad es inversa funcional. Esta propiedad indica que
una asignatura abarca una serie de conceptos nicos para la misma. Las
Asignaturas nos sirven adems para marcar a los alumnos y profesores , y
asignarles permisos.
131
Una instancia de la clase Pregunta est asignada obligatoriamente a una

nica instancia de la clase Asignatura y contempla n Conceptos,
representados como relaciones entre la instancia de la clase Pregunta e
instancias de la clase Concepto. Esta propiedad indica que si se contesta
correctamente a la pregunta se evidencia que se dominan los conceptos con
los que se relaciona.
Como posible mejora al sistema se podra realizar una modificacin que

permitiera compartir preguntas entre asignaturas, ya que en realidad hay
asignaturas que comparten conceptos, suposicin que no se permite en la
ontologa TeML. Para resolver esta restriccin deberamos permitir
relacionar a las instancias de Pregunta y a las instancia de Concepto con ms
de una instancia de Asignatura . De esta forma se podra compartir
preguntas de conceptos comunes entre asignaturas. El sistema propuesto se
puede ver en la Fig. 4.6.
Fig. 4.6. Propuesta de modificacin de la clasificacin pedaggica
4.4.2.3 Realimentacin del sistema: Clculo de la dificultad

Otro punto interesante de la propuesta TeML desarrollada es la propuesta de
utilizacin de las distintas ejecuciones de los exmenes para modificar la
informacin que tenemos de las preguntas. En particular TeML propone que
se utilice para poder recalcular la dificultad de las preguntas.
Como comentamos en el captulo de introduccin, este tipo de

realimentacin de los sistemas permite modificaciones de la informacin
existente por medio de las interacciones de los usuarios. Adems, es esta
posibilidad de adaptacin del sistema en funcin de la informacin nueva
que recoge de los usuarios la que diferencia la formacin on-line de los
132
simples CDs multimedia que contienen contenidos de cursos, por lo que

estudiaremos con ms detalle dicha adaptacin a continuacin.
En la propuesta realizada, el clculo de la dificultad se arranca de forma

manual, es decir, el profesor ha de indicar explcitamente al sistema que
recalcule la dificultad de las preguntas. Tras la orden de reclculo de
dificultades de las preguntas, el sistema aplica un algoritmo que se basaba
en lo siguiente:
El profesor especifica un valor de dificultad inicial a cada pregunta,

que introduce antes de que la pregunta pueda ser utilizada en algn
examen. Dicha dificultad se especifica por medio de un valor entre
0, que indica dificultad mnima, al valor 10, que indica la mxima
dificultad.
El profesor decide la dificultad del examen necesaria, que implica la

dificultad de las preguntas utilizadas, con conocimiento del pblico
al que iba dirigido, es decir, suponiendo que se plantea una dificultad
que permita que, si la destreza de los alumnos a la hora de realizar
un examen se distribuye como una distribucin normal, no aprueben
los alumnos que se consideran del extremo inferior de la normal, los
que sacan peores notas. En [Kel39] se propone que el porcentaje que
se ha de considerar para coger el extremo pero coger suficientes
muestras para que no sean resultados anecdticos es el 27%,
permitiendo el margen 25-33%. Este sistema adopta el 33% (1/3).
Tras realizar el examen se revisa la cantidad de gente que ha

aprobado esa pregunta. En caso que sea mayor que 2/3 significa que
incluso el extremo inferior aprueba, por lo que se debe rebajar la
dificultad. El reclculo se hace restando uno a la dificultad. Para
aumentar la dificultad se supone que han de aprobar no slo el
extremo superior, sino al menos la mitad de la franja media. Por eso
si los aprobados no llegan al 50%, se aumenta la dificultad en una
unidad.
Como podemos contemplar el algoritmo es sencillo, si bien hoy en da se

aaden, a parte del nivel de dificultad, conceptos como si la pregunta est
definida correctamente y el nivel de discriminacin, que indica si llega a
diferenciar realmente entre la gente que saca las mejores calificaciones y la
que saca las peores. Si quisiramos aadir estos parmetros y modificar la
dificultad podramos hacer como especfica [CHA04]:
133
Suponer que cada vez que se hacen los exmenes el perfil de los
alumnos es similar y est distribuido de igual forma. Si no es as
deberamos mantener las estadsticas diferenciadas por perfil.
De nuevo realizar un anlisis EGA (Extreme Groups Approach),

separando los alumnos que han obtenido la mejor calificacin en el
examen y los que han obtenido la peor calificacin. Se considera en
este caso el 25% de alumnos con las mejores notas y el 25% con las
peores. PH es la media en una pregunta de los de mejor calificacin y
PL la media de los de peor. Para calcular la media se supone que la
pregunta se punta entre 0 y 1 (por ejemplo, una de eleccin simple
es 1 si se acierta y 0 si se falla).
Calcular la dificultad como se indica en la expresin 4.1:
( PH + PL ) [Expr. 4.1]
PNCAL =
2
Esta frmula considera que la media de la nota sacada en la pregunta

es la dificultad, de modo que cuanto ms nos acerquemos al 0 ser
una pregunta ms difcil y cuanto ms nos acerquemos al 1 una
pregunta ms fcil. Este algoritmo deja de ser un algoritmo
adaptativo como el algoritmo inicial propuesto en TeML, donde la
dificultad sube o baja un punto. Como la dificultad se calcula de
nuevo sin basarse en los valores de dificultad anteriores, pueden
darse grandes variaciones de valores de dificultad si durante la
realizacin de algn examen se produce alguna anomala, como
puede ser un cambio puntual de perfil de los alumnos.
Por esta razn ser ms recomendable hacer como se indica en la

ecuacin 4.2, donde la nueva dificultad se recalcule a partir de la
antigua, por medio de una variable de memoria [0-1[:
PN 1 ( ) + PNCAL (1 ) [Expr. 4.2]

PN =
2
Calcular la discriminacin como se indica en la ecuacin 4.3:
134
D = PH PL [Expr. 4.3]
De forma que una buena pregunta ha de saber distinguir entre la

gente que ha superado un objetivo de aprendizaje y una que no.
[CHA04] especifica que una D<0.3 significa que esa pregunta debe
ser revisada, ya que no discrimina los que ms saben de los que
menos, y por tanto no sirve a priori para evaluar. En este punto
debemos aadir que esto slo es cierto cuando la dificultad de la
pregunta no es muy alta o muy baja, como se indica en [SIM06].
Podemos considerar que el margen para utilizar la discriminacin es
para dificultades entre 0.3 y 0.7. Denominaremos este margen como
el margen de dificultad aceptable.
Evaluar en las preguntas con opciones las respuestas posibles.

De esta forma revisaremos los enunciados de las posibles respuestas,
tanto si son las correctas como si no. De esta forma evitaremos
plantear opciones que son obviamente incorrectas aunque no se
domine la materia y opciones que aunque se domine la materia no se
entienden como correctas. Consideraremos que una pregunta de
opciones tiene una de sus posibles respuestas incorrecta para revisar
si su dificultad est en el margen aceptable y adems alguna de las
respuestas no la ha contestado ningn alumno de los de peor
calificacin (los que sirven para el clculo de PL). Por otro lado, una
pregunta tiene una respuesta correcta a revisar si su dificultad est en
el margen aceptable y adems la han contestado correctamente ms
alumnos de los de peor calificacin que los de mejor calificacin.
Los mtodos de clculo de dificultad y discriminacin se pueden aplicar

tambin a nivel de examen, utilizando en este caso medias de los valores de
dificultad de las preguntas. Sin embargo en nuestra especificacin no
contemplaremos esta posibilidad y nos centraremos en el clculo de
dificultad de la pregunta para permitir introducir esta informacin en caso
de pretender la interoperabilidad a nivel de pregunta.
Por tanto, vemos que TeML permite una adaptacin de la dificultad de las
preguntas en funcin de las contestaciones de los alumnos, y proponemos en
esta Tesis una modificacin del algoritmo de reclculo de la dificultad de
TeML, basndonos en el modelo EGA con un factor de memoria . Esta
modificacin del algoritmo de clculo de dificultad nos permite localizar
adems preguntas que han de ser revisadas, bien porque no permiten
135
discriminar correctamente o bien porque alguna de sus posibles respuestas

ha de revisarse.
4.4.2.4 Implementacin del modelo

Para implementar el modelo en el ao 2001, se decidi implementar la
ontologa de forma fija por medio de una base de datos relacional, de modo
que los datos de la misma se almacenaban en la base de datos, almacenando
algunos elementos complejos, como la definicin de un examen o la
contestacin de un alumno, en formato XML.
La implementacin se basa en que todos los elementos que actan en el

sistema conocen a priori la ontologa implcita, no estando preparados,
como ocurre en los agentes inteligentes, para adaptarse en caso de
ampliacin de conceptos en la ontologa.
En la Fig. 4.7 podemos ver la descripcin de la Base de Datos relacional.
Fig. 4.7. Descripcin de la Base de Datos utilizada
Como podemos observar, es la propia base de datos, en su descripcin

entidad-relacin, la que indica qu conceptos se pueden relacionar con qu
136
otros y si la cardinalidad de dichas relaciones, que pueden ser [1:N] o

[M:N].
Por ejemplo, una pregunta se representa en la base de datos como un

elemento de la tabla QUESTIONS, y se puede relacionar con mltiples
respuestas, ya que tiene una cardinalidad [1:N] con la tabla ANSWERS. Sin
embargo, tiene una cardinalidad [N:M] con los conceptos, almacenados en
la tabla CONCEPTS.
Tambin podemos apreciar que tanto un alumno, representado como un

elemento en la tabla STUDENTS como un profesor representado en
TEACHER estn relacionados por sendas relaciones de cardinalidad [N:M]
con las asignaturas, representadas como objetos de la tabla SUBJECTS.
La implementacin del modelo se realiza de modo que incluye todos los

subsistemas para que funcione de forma autnoma, de modo que el sistema
de exmenes incluye:
Herramienta de autor para el profesor, que permite la introduccin

de preguntas. Aunque la ontologa permite ms de una respuesta
correcta, la herramienta de autor slo permite preguntas con una
respuesta correcta. Esta herramienta permite, a su ver, la definicin
de exmenes y la consulta de resultados de los mismos.
Herramienta para el alumno, en la que puede contestar a

exmenes que se hayan definido para sus asignaturas y consultar la
nota en caso de corregirse automticamente en el momento.
Sistemas auxiliares de autentificacin, seguridad, correccin

automtica, etc.
Su implementacin fue novedosa tambin por las tecnologas utilizadas,

realizando un sistemas independientes de las plataformas y basado en
software libre. La nica excepcin a este punto ge la Base de Datos, que se
eligi SQL Server(r), aunque el ataque a la base de datos se hace por medio
de SQL estndar y por medio de Java Database Connection (JDBC).
Su implementacin se basa en una separacin en tres capas, que son la

encargada del almacenamiento -realizada con SQL Server-, la capa de
lgica de negocio -implementada por medio de Java y JavaBeans- y la capa
de presentacin -implementada en Java Server Pages (JSP)-. En la capa de
137
lgica de negocio se aaden las restricciones de la ontologa que se

refrendan en la base de datos, como las restricciones de relacin de uno a
muchos y de muchos a muchos, aadindoles denominaciones a dichas
relaciones entre objetos. Por ejemplo:
public class Examen{ [Ej. 4.2]

...
public Pregunta[] getPreguntas() {
...
}
...
}
En este ejemplo vemos que no slo se define la relacin de uno a muchos,

sino que se definen el rango y de la propiedad, siendo una propiedad que
relaciona a un nico examen con varias preguntas.
En cualquier caso, al no utilizar lenguajes ontolgicos para la web, la

ontologa no aparece explicitada en el sistema sino diluida en el cdigo java,
no permitiendo su uso por parte de agentes inteligentes generales que
puedan entender la ontologa y realizar consultas sobre la base de
conocimiento, como s se realizar en la nueva ontologa de teleeducacin
propuesta en los captulos siguientes.
4.4.2.5 Metadatos de la Aplicacin: TeML

Como hemos comentado en los apartados anteriores, en la ontologa descrita
hay un sistema de marcado de los exmenes y las contestaciones de los
exmenes por medio de XML. A esta descripcin en XML se le denomin
tambin TeML, que se basa en la definicin de los metadatos y su expresin
en XML (en este caso por su definicin del DTD).
La metainformacin de TeML se puede dividir segn dos criterios:
1. Segn al objeto al que se refiera. En este caso tenemos la

definicin de un examen (lo que nos permitir obtener informacin
de cmo presentar el examen a los alumnos o si ya se ha realizado,
en qu condiciones se realiz), definicin de los resultados de un
examen y definicin de una pregunta en particular.
2. Segn a qu caracterstica se refiera. En este caso tenemos:
138
- Descripcin de la estructura fsica y su ciclo de vida, as como

datos generales. Equivaldra en parte a los apartados <General>,
<Technical> y <Educational> de IEEE LOM.
- Descripcin de la temtica que trata. En este caso contempla en

parte las categoras <Classification> de IEEE LOM.
- Descripcin de la dificultad. Este punto se trata aparte de la

descripcin de la estructura fsica, ya que la dificultad en s es un
resultado que como hemos visto vara con las interacciones de
los alumnos.
A continuacin nos basaremos en el primer criterio, y dentro de cada objeto

utilizaremos el segundo criterio para agrupar las caractersticas.
4.4.2.6 Metadatos de los exmenes

En el caso de la definicin de los exmenes, en su descripcin de la
estructura tenemos:
Definicin de las preguntas de los exmenes, que veremos ms

adelante.
Ttulo del examen. Una cadena de caracteres que nos servir de

cabecera en la presentacin del mismo.
Autor del Examen. Permite adems aadir un pequeo comentario

de tipo texto por parte del autor, para aclarar un poco la pregunta.
Este apartado de tipo texto es demasiado abierto para situarlo en un
apartado determinado.
Indicacin del Parcial (examen parcial) al que se refiere. No se

considera como descripcin temtica ya que cada parcial puede
contener unos contenidos distintos a lo largo de los aos.
Indicacin de creacin aleatoria del examen. Cuando se marca

esta opcin indica que el examen es aleatorio, y por tanto no incluye
las preguntas determinadas del examen. Para cada persona a la que
se le indica el examen presenta un examen cogiendo las preguntas
aleatorias del pool general de preguntas, fijada la dificultad y la
cantidad de preguntas.
139
Indicacin de los comentarios activados. Si se marca esta opcin,

por cada pregunta, si hay algn comentario de feedback, se
presentar al alumno cuando realice el examen. Esta opcin debe
servir slo para exmenes de autoevaluacin y tiene un cierto
parecido con el apartado de feedbackType de IMS QTI.
Cantidad de preguntas del examen.
Tipo de preguntas, en caso que el examen est compuesto por un

nico tipo de preguntas.
Respecto a la temtica slo habla de la asignatura a la que pertenece y

respecto a la dificultad habla de la dificultad definida del examen , que es la
dificultad de las preguntas a buscar si es de tipo aleatorio o la dificultad
seleccionada por el profesor cuando busc dentro del pool de preguntas.
Como posible mejora proponemos realizar una media de la dificultad de
cada pregunta y colocarlo en este apartado, ya que el profesor, cuando busca
preguntas por una dificultad, le permite elegir tambin un margen de
variacin de la dificultad (como por ejemplo: dificultad 4 2).
Hay otros campos que s contempla el sistema general, y se almacenan en la

base de datos, pero que no se consideraron interesantes como metadatos,
como son la fecha de definicin del examen, que nos podra ser de gran
ayuda para evaluar contextualmente el examen. Por ejemplo, podramos
distinguir el examen que se defini en el curso acadmico 2001/02 para el
primer cuatrimestre.
4.4.2.7 Metadatos de las contestaciones a los exmenes

Para definir la contestacin de los exmenes, para cada respuesta se
almacena en XML la contestacin al examen, pregunta por pregunta. No se
almacena ni variables de tiempo que ha tardado el alumno ni posibles
feedbacks de tipo texto que pudiera indicar el alumno (como no entiendo la
pregunta) y que podran ser de utilidad para la depuracin de las preguntas.
Su nico valor es el almacenamiento del resultado, y podra mejorase por
medio de una firma de ese resultado que permitiese evitar que
modificaciones posteriores de la base de datos corrompieran la informacin.
4.4.2.8 Metadatos de las preguntas

En el caso de la definicin de las preguntas, en su descripcin estructural
tenemos:
140
Tipo de pregunta, que permite definir los siguientes tipos de

enunciados:
a) TipoTexto, donde el enunciado de la preguntas es un simple

texto.
b) TipoImagen, donde el enunciado incluye una imagen.

Incluye datos de presentacin como la posicin a ensear la
imagen, y de localizacin con la URI de la imagen.
c) TipoVideo, similar a TipoImagen pero con un Video.
d) Tiposonido, similar a los anteriores pero sin datos de

posicin. En este caso por defecto aparece un icono que al
pulsarlo reproduce el sonido.
e) TipoFlash, en el que se permite incluir un archivo de flash en

el enunciado.
f) TipoApplet, en el que el enunciado incluye un applet java

que realice una presentacin completa del enunciado.
Tipo de posibles respuestas. Este apartado es similar a los tipos de

preguntas definidos en IMS QTI. Permite definir (aunque slo se
implementa completamente en el sistema las preguntas de opcin
mltiple y simple):
a) Respsimple, para los tipos de pregunta de respuesta simple.
b) Respmultiple, para cuando hay ms de una respuesta

correcta.
c) RespPalabra, cuando la solucin es una palabra.
d) Resptexto, cuando el alumno ha de escribir un texto.
e) RespBarra, cuando el alumno ha de dar un valor desplazando

una barra.
f) RespOrdenar, cuando se ordenan elementos presentados.
141
g) RespAsociar, cuando se asocian parejas.
En la Tabla 4.1 podemos ver la relacin de tipos entre las interacciones de

IMS QTI y los tipos de respuestas de TeML.
TeML IMS QTI

Respsimple choiceInteraction, (con un
ResponseProcessing de respuesta
nica)
Respmultiple choiceInteraction
(ResponseProcessing de respuesta
mltiple)
RespPalabra textEntryInteraction
Resptexto extendedTextEntryInteraction
RespBarra sliderInteraction
RespOrdenar orderInteraction
RespAsociar associateInteraction, matchInteraction
Tabla 4.1. Relacin de Tipos de preguntas
Indicacin de si las respuestas tienen feedback (comentario) o no.

Slo se presentan si el examen lo permite.
Por tanto podemos ver claras similitudes con IMS QTI a nivel de la
preguntas, si bien TeML aade a la metainformacin datos relativos al tipo
de enunciado de la pregunta, por medio del tipo de pregunta. Sin embargo
consideramos que esta informacin se encuentra tambin en IMS QTI por
medio del listado de los ficheros que utiliza, mediante la marca <cp:file> y
por medio de IEEE LOM, donde se define la herramienta y versin
necesaria para poder visualizar correctamente el recurso.
4.5 Conclusiones
En este captulo hemos visto la importancia de las evaluaciones como
interacciones del estudiante en la teleformacin. Adems de enumerar las
ventajas y limitaciones de las evaluaciones, se han descrito dos
especificaciones de evaluaciones y su ontologa relacionada. Una de las
descritas es la especificacin de referencia para la interoperabilidad
actualmente y la otra es una especificacin realizada dentro del
Departamento de Comunicaciones de la Universidad Politcnica de
Valencia.
142
Como hemos podido ver, la ontologa TeML guarda gran similitud con la
ontologa utilizada en IMS QTI, si bien IMS QTI es una especificacin ms
completa en variedad de preguntas y respuestas y descripcin de reglas de
procesamiento de las preguntas. Tambin la definicin actual es posterior a
la definicin de TeML.
Sin embargo, TeML define dificultad de las preguntas y los exmenes, as

como un algoritmo adaptativo para el clculo de la misma. Dicho algoritmo
se modifica en esta Tesis, as como algunos puntos de la ontologa de forma
que se mejora la interoperabilidad en TeML. Es interesante tambin su
clasificacin pedaggica en conceptos, de forma que permite que las
cuestiones sean herramientas que evidencien el dominio o no de uno o
varios conceptos.
Sin embargo, aunque ambas tienen una ontologa en la especificacin,

ninguna de las dos dispone de una representacin en un lenguaje ontolgico
como pueda ser OWL, por lo que hemos de concluir que incluso IMS QTI
adolece de una falta de definicin formal ontolgica, ya que como en el caso
de TeML su ontologa se define en XML, no utilizando ni tan siquiera
lenguajes que permiten relaciones como RDF.
Es por esto que se realizar en esta Tesis una propuesta ontolgica que
intentar abarcar las dos ontologas estudiadas en este captulo, definindola
formalmente y realizando una representacin en OWL, que permitir que
agentes de la web semntica obtengan esa informacin y puedan realizar
razonamientos que faciliten la interoperabilidad de los recursos educativos,
en este caso los tests o evaluaciones.
143
144
Captulo 5. Arquitectura
Captulo 5: Arquitectura
5.1 Introduccin
A lo largo de este captulo elaboraremos una arquitectura que permita el
funcionamiento de la ontologa para teleeducacin que propondremos en el
siguiente captulo. De este modo la arquitectura permitir explotar la
informacin semntica propuesta en la Tesis, y por tanto se generar un
sistema completo de bsqueda y obtencin de objetos educativos.
Entendemos como arquitectura [IEEE00] a la organizacin bsica de un
sistema, compuesto por sus componentes, las relaciones entre ellos y las
relaciones entre los componentes y el entorno, adems de los principios que
rigen su diseo y evolucin.
El objetivo de la ontologa ser permitir la interoperabilidad de los recursos

educativos, por lo que la arquitectura ser una arquitectura de repositorio de
contenidos educativos. Dicha arquitectura ha de permitir adems el uso y
bsqueda por medio de agentes inteligentes, que utilicen la ontologa
145
propuesta en OWL para la bsqueda y obtencin de recursos educativos.

Como hasta donde llega nuestro conocimiento no existe ninguna
arquitectura que cumpla estas especificaciones, definiremos una arquitectura
nueva, que nos permita alcanzar nuestros objetivos.
Para generar la nueva arquitectura, veremos primero las tendencias actuales

respecto a las arquitecturas de repositorios de contenidos, lo que nos
permitir seguir la lnea que mejor se adapte a nuestras necesidades, que
estudiaremos con ms profundidad. Tambin ampliaremos algunos de los
conceptos de las mismas, como las DHT o Tablas Dinmicas Distribuidas,
generando lo que denominaremos DHT Semntica.
La DHT Semntica es una modificacin de las DHT de modo que permite

bsquedas de trminos semnticos y adems optimiza la localizacin por
medio de la separacin de elementos de definicin de las clases de la
ontologas (TBox) y los elementos de definicin de las instancias de las
clases (ABox). De este modo adaptamos las DHT para su uso por OWL DL,
lenguaje que como vimos se basa en las Lgicas Descriptivas que realizan
una separacin ABox/TBox. Por tanto la DHT Semntica ser un elemento
clave y novedoso de nuestra arquitectura, y por esta razn le dedicaremos un
apartado de este captulo.
5.2 Arquitecturas de repositorios de contenidos

educativos
Definiremos un repositorio de contenidos [FED05] como un sistema que
permite a los gestores de contenidos almacenar, localizar, gestionar y
ofrecer recursos de algn tipo. Microsoft sigue la misma lnea, [WWW77]
definiendo un repositorio como una tecnologa que permite compartir
informacin sobre artefactos de ingeniera, entendiendo como artefactos de
ingeniera a cualquier informacin con una estructura compleja y que se
desee compartir. La comunidad de desarrollo en Java define un repositorio
de contenidos [JSR140] de una forma ms restrictiva, limitndolo a un
conjunto de espacios de trabajo, en los que cada uno contiene un rbol de
elementos, y en que cada elemento puede ser un nodo (elemento no terminal
del rbol, que es lo que entendemos en esta Tesis como recurso) o una
propiedad (elemento terminal del rbol). Podemos considerar que la
especificacin en Java de un repositorio de contenidos [JSR140] tambin es
similar, ya que incluye una API que permite el almacenamiento,
localizacin, gestin y descarga de recursos. Sin embargo la definicin que
seguiremos en la Tesis [FED05] es ms generalista al no restringir los
modelos de informacin de los recursos a estructuras de tipo rbol.
146
Si adems, el repositorio de contenidos almacena recursos educativos, lo

denominaremos repositorio de contenidos educativos. Veremos a lo largo
del captulo que aunque hablaremos todo el tiempo de recursos educativos u
objetos de aprendizaje, el desarrollar una arquitectura que trabaje con la
informacin semntica definida en OWL har que pueda trabajar con
cualquier definicin de recursos educativos y adems permitir su uso en
repositorios con otros propsitos, siempre que se publique definicin
ontolgica correspondiente.
Existen actualmente una gran cantidad de soluciones propuestas para los

distintos repositorios de contenidos, pero podemos agrupar las arquitecturas
en tres lneas o tendencias principales:
Grandes repositorios de contenidos o solucin monoltica, donde

recae al menos la tarea de localizacin del recurso en un slo
elemento. Como ejemplo de repositorio de contenidos educativos
tenemos el caso de Merlot [WWW37]. Merlot (Multimedia
Educational Resource for Learning and Online Teaching) es una
iniciativa de la Universidad el Estado de California que recoge e
indexa metainformacin sobre recursos educativos. No contempla
ms que la localizacin del mismo y no su distribucin, que delega
en los servidores en los que se gener el recurso. Uno de los puntos
ms interesantes de Merlot, sobre todo tratndose de recursos
educativos, es su sistema de revisin de calidad de los contenidos
por revisores voluntarios y la recoleccin de opiniones de personas
que lo han utilizado, a modo de acreditacin de la calidad de los
mismos.
Para implementar el gran repositorio de contenidos podemos

basarnos en arquitecturas de un nico servidor (cliente servidor)
como se propone en [DEH06][KIM05],o en arquitecturas Cluster.
Los Clusters normalmente son uniones de elementos homogneos
(igual CPU, forma de comunicarse, sistema operativo) pertenecientes
a un slo dueo. El nmero de elementos del cluster suele ser fijo y
muy limitado, ya que hay una gran centralizacin de los sistemas de
gestin de recursos. Los elementos estn mayoritariamente
dedicados a servir al Cluster.
Sistemas federados de grandes repositorios de contenidos. Es el

caso del repositorio de contenidos educativos Merlot Federated
Search [WWW34], as como de otras arquitecturas en las que se
147
definen y explotan ontologas educativas[SAN05]. El sistema

propuesto de bsqueda es parecido al utilizado por buscadores de
referencias bibliogrficas (como el polibuscador de la Universidad
Politcnica de Valencia, basado en SFX/Metalib [WWW35]), que
por medio de servicios web convierte la peticin de un cliente en
peticiones para los distintos repositorios federados y luego junta los
resultados para presentarlos de forma uniforme al cliente. En este
caso se ataca a los repositorios ofrecidos por Merlot, ARIDANE
[WWW21] y EdNA (Education Network Australia [WWW36].
Otra propuesta de sistema federado para un repositorio de recursos

educativos lo encontramos en la arquitectura propuesta por ADL
para la interoperabilidad de SCORM: CORDRA (Content Object
Repository Discovery and Registration/Resolution Architecture), que
es, como SCORM, un modelo basado en otros estndares para el
diseo de federaciones de repositorios [WWW40].
Una arquitectura que podramos incluir tambin en el apartado de

sistemas federados es la arquitectura Grid. Mientras los Cluster se
basan en elementos iguales, los Grids se basan en una unin de
elementos heterogneos -Normalmente computadores de gran
capacidad con CPUs distintas, distintos sistemas operativos,
ubicados en distintos lugares- de forma que utilizan toda o parte de
sus recursos para obtener un nico objetivo comn, como puede ser
realizar clculos astrofsicos. Se basan en protocolos y estndares
(como los planteados por el Global Grid Forum GGF) aceptados por
todos los elementos, que han llegado a un cierto acuerdo para
obtener el objetivo comn. La tecnologa Grid tiene como objetivo
aprovechar las capacidades infrautilizadas de los sistemas y grandes
sistemas de las empresas y organizaciones, y se denomina Grid
Semntica cuando se convierte en su conjunto en un servicio web y
que adems internamente cada elemento del Grid se relaciona con
los otros por medio de servicios web[ROU05][TUR05].
Sistemas Peer to Peer (P2P) de comparticin de contenidos. En

este apartado se incluyen los sistemas basados en la tecnologa
JXTA como Splash [WWW39] y Edutella [WWW38].
Edutella sea quiz la arquitectura P2P ms conocida para educacin

[NEI02]. Implementa un sistema distribuido de bsqueda sobre
nodos heterogneos utilizando RDF, permitiendo 5 niveles de
148
complejidad de su lenguaje de bsqueda en RDF (RDF-QEL) e

incluso permitiendo compatibilidad con otros lenguajes de bsqueda
en RDF (como RQL).
En realidad Edutella es vlido para cualquier sistema de marcado

con metadatos en RDF. La aplicacin educativa fue la primera y la
ms famosa de Edutella, dedicada a intercambiar informacin RDF
entre Universidades y permitir un sistema de bsqueda distribuido,
que permite bsquedas como las que se realizan en la red e2K
(eMule 2000): locales (en el propio repositorio al que estamos
conectados) o bsquedas globales (preguntando al resto de
repositorios).
Tambin se estn estudiando estructuras mixtas

[TAL03][FOS03][TAL04][BHA05], como por ejemplo Grids que contienen
algunos elementos que son Clusters, y utilizan tcnicas P2P para la
bsqueda de recursos en el Grid y para las aumentar su resistencia a fallos.
Incluso dentro de las arquitecturas P2P, en funcin de lo iguales que sean
todos los nodos entendiendo por igualdad que puedan asumir todas las
funciones del sistema- se habla de sistemas ms P2P puros o sistemas
mixtos, en los que se desarrolla una cierta arquitectura Grid entre
supernodos.
En la tabla 5.1 siguiente podemos realizar una comparacin de las

arquitecturas mencionadas en los grupos de arquitecturas anteriores.
149
Cliente/Servidor Cluster Federados Grid P2P
150
Propietarios 1 por cliente 1 <103 <100 1<x<108
1 del servidor
Elementos >=1 Clientes <103 <103 <104 1<x<108

nico Servidor
Tipo de Servidor altas Optimizados y Gran capacidad y Gran capacidad y Mayora PCs
elementos prestaciones homogneos heterogneos heterogneos particulares (edge
of the web)
Localizacin nico servidor, nica localizacin Distribuidos con Distribuidos con Distribuidos y
Elementos clientes distribuidos localizacin localizacin localizacin
determinada determinada variable
Dedicacin Total (servidor) Total Media Alta Baja

Tolerancia a Baja Baja Media/Baja Media Alta
fallos
Capacidad segn servidor Fija Determinista Determinista Variable
Sistema de Centralizado Centralizado Cierta Cierta distribucin Distribuido
gestin distribucin.
Confianza segn servidor/Total Total segn servidor Alta Baja

Coste de Precio del servidor Alto Medio (utiliza Medio (utiliza Bajo
arranque elementos que ya elementos que ya
existen) existen)
Tabla 5.1. Comparativa de arquitecturas

Como podemos apreciar en la tabla 5.1, las arquitectura cliente/servidor y

cluster son las ms fciles le gestionar, al existir un nico propietario. Sin
embargo, son las menos tolerantes a fallos y las que exigen una mayor
inversin inicial, en la compra del servidor o el cluster. Los sistemas
federados y los grids, por otra parte, utilizan normalmente elementos ya
existentes, por lo que reaprovechan recursos. Estos dos ltimos tipos de
arquitectura contienen elementos distribuidos, pero son localizables y a los
que se les puede suponer cierta confiabilidad, ya que normalmente existe un
acuerdo entre los dueos de los elementos participantes para seguir unas
reglas. Sin embargo, si queremos llegar a grandes niveles de escalabilidad,
de forma que podamos servir a una gran cantidad de agentes distribuidos
por la web debemos de recurrir a otro tipo de arquitectura.
Las arquitecturas ms escalables y que permiten la mayor entrada de

elementos son las arquitecturas P2P. Adems estas soluciones son ms
tolerantes a fallos y tienen un coste de arranque ms bajo. Sin embargo, es
en estos sistemas en los que existe menos confianza entre sus miembros, y
al ser arquitecturas tan distribuidas su control es complicado, siendo sus
valores de rendimiento ms difciles de evaluar, ya que se basan en muchos
casos en valores probabilsticos.
Para poder disear la arquitectura ms ptima para nuestros propsitos,

primaremos la escalabilidad de las arquitectura P2P y su tolerancia a fallos,
por lo que estudiaremos a partir de este punto las arquitecturas P2P y
desarrollaremos soluciones que permitan atenuar los inconvenientes de
confianza y control.
De hecho, en la actualidad las arquitecturas de red Peer to Peer son las ms

utilizadas para la distribucin de contenidos multimedia. Segn CacheLogic
[WWW31], en diciembre de 2004 el trfico de sistemas P2P superaba ya el
60% de todo el trfico que circula por Internet. La causa de su auge radica
en que generan grandes ventajas, sobre todo dirigidas a la supervivencia de
dichas redes, ya sea ante grandes crecimientos de demanda, fallos de partes
del sistema o ataques informticos. Dicha supervivencia se manifiesta
tambin ante los ataques legales -la localizacin y obligacin de cerrar
nodos por distribucin de contenidos ilegales- por medio de la utilizacin de
sistemas de encriptacin, anonimato y reparticin de responsabilidades entre
todos los miembros de la red, que pueden aparecer y desaparecer
continuamente. Este ltimo punto hace surgir la duda de hasta qu punto son
las arquitecturas P2P beneficiosas para el diseo de una arquitectura
151
orientada a la distribucin de contenidos, pero con la necesidad de mantener

y potenciar los derechos de autor. Este ser otro de los puntos que
intentaremos resolver en nuestra arquitectura, estudiando las distintas
posibilidades que se plantean en las arquitecturas Peer to Peer.
5.3 Arquitecturas P2P

Una arquitectura Peer to Peer se define como una arquitectura en que los
nodos tienen el mismo nivel, en el sentido que cada nodo es capaz de
realizar cualquiera de las funciones necesarias en la arquitectura, y en la
prctica muchas funciones del sistema estn distribuida entre muchos de los
nodos [WWW30].
Por tanto podemos entender como una red P2P a una red en la que no
existen clientes y servidores prefijados, sino un nmero de nodos iguales
que pueden funcionar a la vez como clientes y servidores para otros nodos
de la red.
CLIENTE/SERVIDOR PEER TO PEER
CLIENTE
CLIENTE Y SERVIDOR
CLIENTE Y SERVIDOR
SERVIDOR CLIENTE Y SERVIDOR
CLIENTE
CLIENTE Y SERVIDOR
CLIENTE CLIENTE Y SERVIDOR
CLIENTE
CLIENTE Y SERVIDOR
Fig. 5.1. Sistema Cliente-Servidor frente a un Sistema P2P
En la figura 5.1 podemos apreciar la diferencia entre la clsica arquitectura

cliente/servidor y la arquitectura P2P. En la primera existe un nodo
principal, llamado servidor, que realiza la mayora de las funciones y al que
han de conectarse directa o indirectamente el resto de nodos, que son
152
clientes de este nodo principal. Por otro lado, en la arquitectura P2P

podemos observar que no existe ningn nodo que destaque en un principio
de los otros, y no es un punto crtico mantener la conexin con un nodo
determinado. De hecho, cada nodo puede ser a la vez cliente y servidor de
otros nodos de la red.
Los usos principales de las arquitecturas P2P se pueden agrupar en:
Comparticin de ficheros, como utilidad ms extendida y famosa.

como ejemplo podemos tener una aplicacin eMule funcionando en
la red Kad. Tambin hay pruebas de comparticin de ontologas (a
nivel de RDF o no estndar), como son el caso de SWAP[SWAP04]
y su continuacin Oyster [PAL06].
Computacin paralela, como en SETI@home, donde un servidor

reparte partes del proceso de datos a los nodos, los nodos procesan
los datos y envan los resultados de nuevo al servidor. Aunque existe
una centralizacin en el reparto de datos y la recepcin de resultados,
el clculo del los mismos los puede realizar cualquier nodo
disponible.
Redes de Distribucin de Contenidos (CDNs), como la Coral

Content Delivery Network [WWW33], donde se pretende hacer un
sistema que cachee pginas de internet para poder ofrecerlas cuando
el servidor que las ofrece est saturado o haya cado. El almacenaje
de esas pginas cacheadas se reparte entre los nodos de la red.
Comunicaciones entre usuarios, como por ejemplo Skype o

herramientas de chat, donde no es necesario un servidor que
centralice las comunicaciones, y existe una bsqueda distribuida en
la red.
Realizar bsquedas distribuidas en la red. De hecho, existen

muchos sistemas P2P que utilizan estos sistemas de bsquedas
distribuidas para localizar nodos o recursos dispersos.
Para implementar herramientas de interaccin directa entre

usuarios, como juegos y herramientas de colaboracin. De nuevo la
inexistencia de servidores intermedios mejoran los rendimientos y
permiten mayor independencia y tolerancia a fallos.
153
Las arquitecturas P2P se desenvuelven en sistemas altamente heterogneos,

con grandes probabilidades de cada de los elementos que lo componen, lo
que hace que se diseen en gran medida como sistemas extremadamente
tolerantes a fallos. Adems los elementos, en lugar de buscar un objetivo
comn, buscan su propio objetivo particular, lo que hace que no se puedan
planificar las tareas y existan grandes variaciones de demanda del sistema.
Se basa normalmente en su mayora en ordenadores personales donde los
dueos no se conocen.
5.3.1 Desarrollo de las arquitecturas P2P

Se pueden clasificar las arquitecturas en varias generaciones [FOS03],
[XIE03], que van consiguiendo ser cada vez ms independientes de sistemas
centrales y a su vez optimizando los algoritmos de bsqueda de recursos. En
nuestro caso dividiremos las arquitecturas en tres generaciones:
1. Arquitecturas P2P de primera generacin, con elementos

centralizados, como es el caso de Napster (cuya bsqueda de
recursos se haca por medio de un sistema de indexacin
centralizado) o SETI@home, sistema que se basa en un servidor que
enva a los nodos trozos del ruido detectado por las antenas que
apuntan al espacio para intentar buscar patrones que puedan indicar
inteligencia. Ya en esta primera generacin, en caso de descarga de
contenidos se realiza entre el interesado y el propietario del recurso
(peer to peer).
Estas arquitecturas de primera generacin sirvieron para probar el

potencial de clculo y almacenamiento de los PCs de los usuarios de
internet el potencial de los elementos terminales de la web- as
como para demostrar que los sistemas centralizados no son los ms
adecuados cuando hay un gran crecimiento en nodos, ya que por
muy rpidos en el clculo, mucha memoria que tengan y mucho
ancho de banda, es insuficiente ante crecimientos exponenciales de
miles de nodos.
2. Arquitecturas de segunda generacin, donde ya se distribuyen las

tareas, pero se basan en protocolos de enrutamiento y comunicacin
del tipo inundacin -mandar el mismo mensaje por todos los nodos-
u otros protocolos poco eficientes para un nmero grande de nodos.
Para evitar saturaciones de red por el reenvo de mensajes, se utilizan
sistemas de TTL -saltos de un mensaje antes de que desaparezca-y
154
en otros casos se permite la funcin de bsqueda slo entre

supernodos. Se entiende como supernodos a un subconjunto de los
nodos de la arquitectura que son los que se utilizan para indexacin,
es decir, nodos en donde se indexan las bsquedas. Como ejemplos
de estas arquitecturas tenemos las generadas por el protocolo
FastTrack, protocolo usado por Kazaa [WWW32] o la arquitectura
por defecto de JXTA, con sistemas de descubrimiento basados en
multicast [JXTA1],[JXTA2]. Un sistema ms avanzado que
FastTrack es la red Gnutella2 y eDonkey 2000 (cerrada en
septiembre de 2006 por Recording Industry Association of America,
-RIAA-, aunque sigue en versiones como eMule), basados en nodos
que tienen la libertad de decidir si participan como servidores de
bsqueda supernodos- o no.
3. Arquitecturas de tercera generacin. Estas arquitecturas se basan

actualmente en Distributed HashTables (DHTs), que son algoritmos
que permiten que una tabla dinmica Hashtable que trabaja con
pares [clave, valor]- se encuentre distribuida en la red y permita
bsquedas y almacenajes en la misma, aunque el nmero de nodos
crezca. Estos algoritmos se utilizan en la red Kad, red utilizada por
las nuevas versiones de eMule y por las nuevas versiones de
BitTorrent. Mientras en otros sistemas la clave era el resultado de
aplicar una funcin hash al contenido del documento, en este caso se
indexa por funciones hash de las palabras de las que se compone el
nombre del documento, permitiendo una simple bsqueda por
palabras clave.
BitTorrent es destacable sobre todo por su algoritmo de distribucin

de los contenidos. En este caso ya no se descarga el contenido de un
nodo fuente, sino que se elabora una subred -llamada enjambre-
dedicada a la distribucin de un nico fichero, entre uno o varios
nodos que contienen la fuente, llamados semillas (seeds) y los nodos
que se estn descargando la fuente, de modo que se divide el gran
fichero en fragmentos y cuando un nodo que hace de cliente tiene
completo un fragmento ya puede compartirlo con los otros miembros
de la subred.
Como hemos visto las generaciones han ido avanzado, de modo que al
principio las funciones que podan realizar los nodos annimos eran la de
descarga de un contenido a otro nodo, y poco a poco han ido distribuyendo
tambin entre todos los nodos la funcin de indexacin y localizacin de
155
recursos, distribuyendo tambin la tarea de descarga de un contenido a un

gran nmero de nodos receptores. En el desarrollo de nuestra arquitectura
nos basaremos en la tercera generacin, puesto que buscaremos una gran
escalabilidad a la hora de indexar los contenidos ontolgicos que nos
permitan luego el acceso a los objetos educativos que pretendemos
compartir.
5.3.2 Ventajas de las arquitecturas P2P

Aunque las hemos comentado por encima en el apartado anterior, las
mayores ventajas de las arquitecturas P2P son
[COO02][HAA04][ALO05],[SIE05]:
Alto grado de escalabilidad. Al no haber centralizacin de

funciones, los sistemas P2P estn diseados para que cada nodo
nuevo que entra pueda aportar a su vez recursos utilizables por la
red. Los protocolos a utilizar se disean de forma que al crecer a n
nodos las necesidades del sistema para los encaminamientos sean del
orden de Olog(n).
Gran capacidad de adaptacin a las dificultades, ya que existe una

cierta duplicidad de datos y posibilidad de absorber tareas de otros
nodos que por alguna razn caen. En un sistema P2P puro no deben
existir cuellos de botella ni tareas crticas asignadas a nodos
determinados.
Encontramos un ejemplo de adaptacin a las dificultades la solucin

encontrada para utilizar nodos que estn detrs de un subsistema que
impide a otros nodos que contacten con ellos directamente. Estos
nodos -conocidos como nodos LOWID en eMule- tienen cortadas las
conexiones de entrada por un cortafuegos o no conocen su direccin
IP porque estn detrs de un traductor de direcciones de red (NAT).
En estos casos, algunos sistemas -como eMule o Skype- se basan en
utilizar nodos repetidores que actan dejndose conectar por los dos
nodos que quieren comunicarse, y as el nodo que era destino de la
conexin no est obligado a ofrecer puertos de entrada abiertos.
Podemos ver el esquema de funcionamiento en la Fig. 5.2.
156
Fig. 5.2. Nodo repetidor
Como podemos apreciar en la figura 5.2, se genera una conexin

virtual donde el nodo B permite la entrada de la conexin virtual.
Dicha conexin virtual se lleva a cabo por medio de dos conexiones
reales con un nodo repetidor, donde el nodo repetidor recibe las
conexiones del nodo A y B.
Podemos ver otra adaptacin que tiene como propsito evitar la

avaricia de recursos, es decir, nodos que se aprovechan de la red y no
ofrecen a la red recursos suficientes. Considerando como recurso la
posibilidad de recibir conexiones inesperadas de entrada, vemos que
los nodos LOWID no pueden actuar como nodos repetidores y por
tanto ofrecen menos recursos que los que permiten ser utilizados
como nodos repetidores. En este caso se penaliza a los nodos
LOWID con menores capacidades de uso de la red, por ejemplo, un
ancho de banda de bajada muy bajo.
157
Resistencia los ataques a la red, ya que normalmente los ataques a

la red se hacen buscando los lugares ms dbiles y sobrecargndolos.
En este caso no hay puntos fuertes ni dbiles. De todas formas, los
sistemas distribuidos han de tener algoritmos que eviten en todo
momento realimentaciones positivas que hagan que el propio
sistema entre en bucles de crecimiento de carga. Como ejemplos de
estas protecciones a las realimentaciones positivas tenemos el hecho
de no volver a consultar nodos que ya se han consultado, y la
utilizacin de paquetes con un nmero determinado de saltos antes
de que desaparezcan.
Adaptacin a los picos de demanda, ya que la carga est

distribuida entre todos los nodos de la red. De esta forma, por
ejemplo, un aumento de demanda a la red en un valor X se convierte
normalmente en un aumento de demanda X/N para cada uno de los
N nodos que satisfacen dicha demanda. Adems, cuando el aumento
de demanda se debe a la aparicin de nuevos nodos, estos nuevos
nodos se unen normalmente a la red para prestar sus servicios. Un
ejemplo de esta adaptacin es el protocolo BitTorrent, donde cada
nodo que solicita un fichero se convierte a su vez en posible servidor
de la parte del fichero que ya se ha descargado.
Bajo coste de arranque y mantenimiento, de forma que si

conseguimos que todo nodo que se conecte se beneficie de alguna
forma, no hace falta comprar grandes ordenadores que lleven un
seguimiento centralizado. Llegados a este punto es importante
destacar que es mucho ms eficiente invertir en un cluster que
comprar una gran cantidad de nodos para implementar una red P2P,
en el caso que no pueda utilizar nodos de otros propietarios. Toda
red P2P consume en conjunto ms recursos que un ordenador
monoltico realizando la misma funcin, ya que existe una gran
redundancia, que es una de las razones por las que el sistema es tan
resistente. Sin embargo, cuando hablamos de rdenes de magnitud
de 108 nodos, aunque se produzca redundancia y no se utilice el
potencial de cada nodo al cien por cien, la capacidad total es mayor
que cualquier sistema monoltico existente.
158
5.3.3 Inconvenientes de las arquitecturas P2P

Las propias caractersticas de las arquitecturas P2P llevan aparejadas ciertas
desventajas que pueden ser aceptadas o no segn la funcin del sistema que
queramos desarrollar. Podemos enumerar las siguientes
[ALO05][VER04][GER03]:
Falta de determinismo. La gran escalabilidad de los sistemas hace

que para una gestin de un nmero tan elevado de posibles nodos, se
recurra a tcnicas probabilsticas. Esta falta de determinismo acarrea
desventajas, como que los tiempos de respuesta de la red sean muy
variables y difcilmente asegurables.
Imposibilidad de una localizacin fija de recursos. Cada vez que

se accede de nuevo a un recurso no se puede asegurar que se
encuentre en el mismo nodo en el que estaba, ya que existe una
reconfiguracin y relocalizacin de recursos dinmica. Lo que es una
ventaja para proteger el sistema ante cadas de un nodo se convierte
aqu en una desventaja. En cualquier caso una prctica habitual es las
redes P2P es acceder primero a los que nos ofrecieron servicio con
anterioridad, de modo que los utilizamos como puntos de acceso a la
hora de entrar de nuevo en la arquitectura.
Dificultad de imponer autoridades en el sistema para control. La

propiedad de disponer de sistemas de control distribuidos es una
ventaja contra ataques o cadas, pero para determinados casos puede
ser un gran problema. Por esta causa se han de disear sistemas que
permitan regular y controlar a los nodos que no se comportan como
se espera de ellos. Algunos sistemas realizan la distribucin del
control, por medio de sistemas de crditos -como eMule-, y elaboran
rankings de mejores nodos a los que el sistema ofrece mejores
servicios.
Dificultad de detectar los nodos maliciosos. No solamente es

difcil actuar sobre los nodos maliciosos, sino que muchos sistemas,
que priman el anonimato y la confusin respecto a los nodos que
solicitan un recurso, hacen que sea complicado la localizacin de
algn nodo que est daando al sistema, por ejemplo por medio de
envos masivos de peticiones y negativa de servir al resto de nodos.
Falta de confianza. Al no conocer los otros nodos de la red, es de

esperar cierta desconfianza respecto a los servicios que nos
159
proporcione. Como ya hemos visto, en otras arquitecturas esto no

ocurre. Por ejemplo, en las arquitecturas Grid, conocemos a los
proveedores de los nodos. Encontramos otro ejemplo en las
arquitecturas clientes/servidor, donde todo depende de la confianza
que tengamos en ese nico servidor. En arquitecturas P2P, la
estimacin de confianza en un nodo se suele realizar en algunos
sistemas tambin de forma distribuida por medio de sistemas de
crditos- y hemos de apoyarnos en firmas digitales y cdigos hash de
los recursos para asegurar la autenticidad de los mismos.
Limitacin de los servicios ofrecidos. Una aplicacin P2P ha de

estar funcionando en una gran cantidad de nodos antes de que el
sistema sea realmente til para todos los participantes, por lo que es
ciertamente difcil generar aplicaciones P2P que sean exitosas en la
web. Adems, normalmente se exige una cierta apertura del cdigo
(por ejemplo GPL) que permita comprobar a las comunidades que la
aplicacin P2P no es daina para los propios nodos y que no realiza
ninguna accin maliciosa.
Necesidad de polticas win-win. Para que el sistema sea aceptado

por una gran cantidad de nodos, los nodos han de estar
individualmente interesados de alguna forma en los servicios que se
ofrecen. Su inters ha de ser tan alto que permitan el uso de sus
recursos a cambio de esos beneficios. No todos los sistemas pueden
ofrecer una ventaja que haga que entren nodos. De hecho los
sistemas P2P normalmente se enfocan en sistemas no comerciales en
los que el pago por los servicios es la misma participacin en los
mismos.
5.4 Distributed HashTables (DHT)

Como hemos comentado, la tercera generacin de sistemas P2P se basan en
el desarrollo de algoritmos que permiten la bsqueda distribuida de los
recursos, por medio de la generacin de tablas dinmicas distribuidas.
Definimos una tabla dinmica distribuida (DHT) como una Hashtable que
trabaja con pares [clave,valor], encontrndose distribuida en la red y
permitiendo bsquedas y almacenajes en la misma, aunque el nmero de
nodos crezca o disminuya dinmicamente. Para realizar esta tarea las DHT
se fundamentan en unos algoritmos que veremos a continuacin.
160
Normalmente las claves de las DHTs suelen ser una transformacin por
medio de una funcin hash del recurso que queremos buscar, y el valor de la
tabla indica la direccin URL del nodo que puede ofrecerlo. En los casos de
redes de distribucin de ficheros, la clave suele ser la funcin hash del
fichero que buscamos y el valor la direccin URL de donde podemos
descargarnos el fichero en el que estamos interesados.
Como podemos ver en la figura 5.3, las DHTs nos permiten demandar los
siguientes servicios:
Unirnos a la subred P2P que configura la DHT, ya que en cierto

modo la DHT es una red P2P que permite la localizacin de recursos
en otra red P2P.
Salir de la red, cuando estamos unidos a la red. El sistema permite

que haya salidas inesperadas y no notificadas de la red.
Buscar contenidos segn la clave, normalmente cuando estamos

unidos a la red, de forma que colaboramos con la misma. El
resultado de la peticin es el valor asociado a esa clave en la tabla
dinmica o la incapacidad de encontrar dicho valor.
Insertar un par (clave, valor) en la DHT, de nuevo normalmente

cuando estamos unidos a la red, de modo que cedemos recursos a
cambio de obtener los servicios de la DHT. El resultado es que el par
(clave, valor) queda insertado en la DHT y podr ser consultado por
otros nodos
161
NODO
SA
R
A
BUSCAR (K)
INSERTAR
LI
TR
R
EN
(K,V)
DHT
NODO NODO NODO NODO NODO
INTERNET
Figura 5.3. Servicios ofrecidos por las DHT
En la figura 5.3 podemos apreciar a su vez que las DHT se sustentan

normalmente en un conjunto de nodos que se han unido a la DHT y que
normalmente se unen entre s por medio de la red internet. Un nodo puede
realizar las peticiones de entrada si no pertenece a la DHT, de salida si s
que pertenece y luego las peticiones tpicas a una tabla dinmica.
Las bases de los DHTs son:
1. Las claves han de estar distribuidas aleatoriamente y de forma

uniforme, siendo nicas. Esto se suele hacer por medio de pasar
una funcin hash a la fuente (nombre de la fuente, contenidos del
fichero, etc). Para evitar repeticiones se usa un espacio de valores de
20 bytes (160 bits) que nos da de orden de 2160 (1048) valores. Para
hacernos una idea de la magnitud del espacio de valores, en la Tierra
162
hay del orden de 2170 tomos. Algunos sistemas, como e-Mule,

utilizan espacios de 128 bits, considerndolos suficientemente
amplios.
2. Los identificadores (IDs) de los nodos han de estar distribuidos a

su vez aleatoriamente y de forma uniforme, siendo nicos. Esto
se suele hacer a su vez pasando una funcin hash (normalmente
SHA-1 que genera 160 bits) a la direccin del nodo.
3. Se define una topologa, donde se define una funcin distancia

entre nodos, y el nmero de nodos conectados a un nodo
determinado. En este caso el concepto de conexin se refiere al caso
en el que el nodo conoce las direcciones IP de los nodos con los que
est conectado, y por tanto se consideran como conexiones directas
sobre la red P2P superpuesta a internet.
4. Se hace que los nodos almacenen los valores de la DHT (clave,

valor) cuyas claves estn cerca (segn la topologa elegida) del ID
del nodo. Al estar distribuidos aleatriamente tanto las claves como
los nodos, la carga se reparte por igual entre los nodos.
5. Se proveen algoritmos para que un nodo pueda entrar

conociendo un nodo que est ya en la red P2P de la DHT, se
coloque en el lugar que le corresponde y almacene los valores de la
hashtable que le correspondan. Adems se proveen mecanismos
distribuidos para que en caso de abandono o cada inesperada de un
nodo, se pueda recuperar el sistema. Este ltimo punto se lleva a
cabo normalmente haciendo que cada nodo cachee la parte de la
hashtable de j nodos que estn cerca de l.
Como podemos ver en la tabla 5.2, segn topologas y definicin de

distancias se obtienen unos algoritmos u otros. Se consideran mejores
sistemas los que necesitan menos saltos en las consultas de la DHT y menos
tiempo y menos mensajes generados a la hora de que un nodo entre o salga
de la DHT.
Nombre Topologa Saltos en Conexiones a

bsqueda recordar
CHORD circular Olog(n) Olog(n)
CAN toroidal de d O(dn1/n) d
dimensiones
163
PASTRY malla Olog(n) Olog(n)

TAPESTRY malla Olog(n) Olog(n)
PLAXTON malla Olog(n) Olog(n)
DB2 De Bruijn Olog(n) O(1)
CRN Mariposa Olog(n) Olog(n)
KADEMLIA malla Olog(n) Olog(n)
Tabla 5.2. Comparativa de algoritmos para DHT. Basada en [XIE03]
En la tabla 5.2 podemos apreciar los diferentes algoritmos de DHT en

funcin de la topologa elegida. Los primeros algoritmos que surgieron
fueron [MAY02] CHORD (utilizado en CCDN), CAN (basado en una
topologa d-dimensional pero con una complejidad de ejecucin del
algoritmo alta y con peor escalabilidad). Los algoritmos Pastry, Tapestry y
Plaxton y Kademlia se basan en una topologa de malla (segn los 1s o
0s de su id de nodo) aunque el ms utilizado es Kademlia [MAY02], al
ser ms ptimo para redes muy grandes. Kademlia es actualmente la base de
la red Kad sobre la que funciona eMule.
El algoritmo Kademlia se basa en una distancia definida como la or

exclusiva entre los puntos.
( a, b) = a b [Ec 5.1]
Las ventajas de la topologa derivada de la distancia en Kad respecto a los

otros algoritmos son la simetra y la unidireccionalidad. La simetra permite
que, en el caso en que un nodo tenga cerca a otros nodos, stos lo tengan a
l tambin como nodo cercano. La unidireccionalidad de la distancia
permite que slo haya un nodo a una distancia D del nodo X, de forma que
las bsquedas de la misma clave suelen acabar pasando por los mismos
nodos segn nos acercamos al nodo buscado.
La simetra nos permite aprovechar los mensajes que nos llegan de

bsqueda para comprobar que los contactos del nodo son correctos, y por
tanto no necesitamos cargar la red con ms mensajes de control. La
unidireccionalidad nos permite hacer que los nodos por los que ha pasado
una peticin cacheen el resultado de la peticin, ya que es posible que
cuando se pida el mismo recurso de nuevo pasen por ellos.
En el algoritmo Kademlia, cada nodo ni tiene una lista llamada bucket- de

otros nodos por cada bit del tamao de las claves, de modo que tiene 160
buckets cuando tratamos con claves de 160 bits. En cada bucket de la
164
posicin j (bj) almacena informacin para contactar con un mximo de k

nodos (k normalmente=20) que distan de ni el orden de magnitud 2j (es
decir, que coinciden en los bits j+1 a 159 (si son claves de 160 bits) y difiere
al menos en la posicin j, pudiendo diferir o no en los bits 0 a j-1. Puede que
algunos buckets estn vacos, sobre todo los de valores i ms bajos. Para
elegir los mejores nodos a conectarse dentro de un bucket se premia los que
llevan ms tiempo en la red, ya que se basa en la suposicin de que cuanto
ms tiempo lleva un nodo en la red ms probable es que contine en ella.
El algoritmo Kademlia contempla tambin que cada nodo lance mltiples

bsquedas paralelas al siguiente salto de bsqueda. El nmero mximo de
peticiones paralelas por nodo se fija por medio de una variable , a la que se
recomienda se le asigne el valor de =4.
5.5 Arquitectura propuesta

A partir de este punto, tras ver las distintas arquitecturas, haber decidido
definir una P2P por razones de escalabilidad y robustez, y despus de haber
visto con detalle las distintas posibilidades de arquitecturas P2P pasamos a
definir con detalle la arquitectura sobre la que funcionar la ontologa OWL
y que permitir su uso por parte de agentes inteligentes que busquen
recursos educativos.
Pretendemos que la arquitectura propuesta cumpla los siguientes requisitos:
Permitir bsquedas por agentes inteligentes de los contenidos

ontolgicos. De esta forma podrn actuar los agentes inteligentes y
obtener la informacin en OWL o sistema equivalente. Esto significa
que los agentes inteligentes no disponen en un principio de toda la
informacin lgica necesaria para realizar sus razonamientos, sino
que puede que pidan al principio y luego vayan ampliando su base
de conocimiento, tanto de su TBox como de su ABox.
Los sistemas sern sistemas conectados a Internet, por lo que se

disear una red sobre Internet (overlay net). Se define una red sobre
internet [KER04][AKE04] como una red que consiste en una serie
de nodos preseleccionados, localizados en una o varias subredes, y
conectados entre s por medio de un enrutamiento a nivel de
aplicacin, aunque se sigue conectando por medio de la red IP. Al
realizar el enrutamiento a nivel de aplicacin, existe un mayor
control sobre las conexiones y se pueden aplicar algoritmos de
seleccin de conexiones particularizados.
165
Permitir una distribucin rpida de contenidos, evitando en la

medida de lo posible la distribucin de contenidos con copyright de
forma libre.
Soportar cierto grado de escalabilidad. En este caso trabajaremos

con soluciones P2P adaptadas, que permitan grandes picos de
trfico, si bien se realizar un cierto control.
Permitir un funcionamiento mnimo del sistema, de forma que si

acude un primer cliente al sistema pueda realizar bsquedas y
obtener los objetos educativos deseados.
Identificacin de las fuentes. Si en otros sistemas peer to peer el

anonimato es premiado, al menos en nuestro sistema identificar los
orgenes de los objetos educativos es positivo para evaluar su posible
calidad a priori.
Todos estos requisitos se contemplarn en una arquitectura P2P con ciertas

modificaciones, principalmente modificaciones que faciliten el trabajo con
la web semntica y agentes inteligentes y permitan la identificacin de las
fuentes de los contenidos.
5.5.1 DHT Semntica

Para permitir el uso de la arquitectura por parte de agentes inteligentes que
trabajan en la web semntica, tendremos que adaptar los sistemas de
localizacin de recursos para que puedan funcionar con trminos lgicos y
permitan una rpida adquisicin de conocimientos por parte de los agentes.
Para hacer este sistema de localizacin de la arquitectura que diseamos, y
al no existir ningn sistema en la actualidad que resuelva esta cuestin,
definimos en esta Tesis un sistema que denominaremos DHT Semntica,
que describiremos a continuacin y que permite el trabajo con la web
semntica en redes P2P de tercera generacin.
La arquitectura propuesta se fundamenta en un sistema de bsqueda P2P

basado en las DHT explicadas anteriormente. En este caso se escoge
tambin el algoritmo Kademlia. Una de las diferencias principales radica en
que las claves de la tabla dinmica distribuida sern la funcin hash de las
URIs utilizadas para describir ontologas, clases, propiedades e instancias en
OWL. De esta forma, en lugar de realizar bsquedas de URLs donde se
pueda localizar un fichero determinado, los agentes podrn buscar URLs
166
donde se encuentren ficheros OWL que ofrezcan informacin acerca de un

elemento de la ontologa clase, instancia o propiedad- determinado.
Para poder realizar estas bsquedas, la informacin que debe almacenar

cada nodo de la DHT semntica ser la informacin para poder localizar el
servidor de contenidos que gener cada uno de los ficheros relacionados.
Adems, un nodo deber almacenar si el fichero OWL del que almacena su
localizacin contiene informacin de descripcin de clases y propiedades
(TBox) y si contiene informacin sobre instancias de la ontologa (ABox).
Aunque en OWL DL la informacin de la TBox y de la ABox no se
mezclan (una clase no puede ser a su vez una instancia de otro tipo de
clase), s que es posible que un mismo fichero contenga informacin de los
dos tipos.
Esta peculiaridad de marcar los contenidos segn el tipo de informacin que

contiene sera otra de las modificaciones importantes respecto a las redes
existentes basadas en Kademlia (como la red KAD), por lo que se puede
colocar esta informacin en alguno de los campos no utilizados de la red
particular sobre la que construyamos. La causa por la que separamos
explcitamente la informacin de la TBox y la informacin de la ABox
radica en que la descripcin de clases y sus relaciones (TBox) ser la
informacin a la que primero accedern los agentes ya que asienta las
bases de la ontologa- y por regla general tendr muchos menos elementos a
indexar que la informacin ABox, que trata de las instancias y las relaciones
entre las mismas. Por ejemplo, una ontologa de cursos no debera tener ms
de un centenar de elementos (URIs distintas) en su TBox, mientras que
instancias de esos elementos (como por ejemplo, comentarios unitarios de
foros que pertenezcan a todos los cursos registrados en la red) puede haber
ms de 105.
Otra diferencia destacable entre esta red y una red DHT normal, a parte de
que indexa contenidos semnticos y los marca como TBox y/o ABox, es que
son los servidores de contenidos los que publican (tcnica push) en la DHT
Semntica su informacin. Para realizar esta publicacin, los servidores de
contenidos han de basarse en una arquitectura que les permita que cuando
tengan nueva informacin semntica que publicar, la analicen y den de alta
como claves de la DHT Semntica todas las URIs utilizadas como clases,
propiedades e instancias del documento OWL.
Por ejemplo, si un servidor de contenidos desea publicar una edicin

antigua de un curso, describiendo tanto los contenidos como las
167
interacciones de los alumnos y profesores, generarn el archivo .owl y luego

lo transformar por medio de capa de publicacin en un conjunto de claves
y valores de URLs que insertar a modo de entradas en la DHT. Por medio
de este mecanismo, por cada URI que tenga algn significado en la
ontologa se publicar en la DHT Semntica un par (hash(URI), URL) que
permitir a los agentes localizar la URL donde se encuentra el fichero OWL
que describe de alguna forma el elemento ontolgico identificado por la
URI. No es necesario utilizar un archivo para describir cada objeto
educativo o experiencia educativa, sino que se pueden agrupar, aunque para
mejorar las prestaciones se recomienda no utilizar archivos muy grandes con
informacin de TBox (ya que es la que ms se accede a priori) o incluso
intentar mantener los archivos con informacin de TBox separados de
cualquier informacin de la ABox..
En la Fig. 5.4 podemos ver la arquitectura de DHT Semntica, detallando

las funciones a realizar por parte del servidor de contenidos.
168
BUSCAR (K1, TBox)
DHT SEMANTICA
AGENTE V = OWL URL
INSERTAR (K2,V, ABox)
INSERTAR (Kn,V,ABox)
INSERTAR (K1,V,TBox)
OWL
OWL URL
PUBLICADOR
DISTRIBUIDOR DE CONTENIDOS
SEMNTICOS
GESTOR DE PUBLICACIN DHT
OWL
ALMACEN INFORMACION
SEMNTICA
.OWL
EXTRACTOR DE INFORMACIN SEMNTICA
LO-A LO-B LO-C
OBJETO A OBJETO A OBJETO A

DESCRIBIR DESCRIBIR DESCRIBIR
Fig. 5.4. DHT Semntica
Como podemos apreciar en la figura 5.4 el servidor de contenidos dispone

de un elemento funcional encargado de la publicacin en la DHT Semntica
y facilitacin de documentos OWL a los agentes. A este elemento lo
denominaremos publicador. El publicador primero extrae la informacin de
descripcin de los objetos educativos a describir, en este caso LO-A, LO-B
169
y LO-C. Con esa informacin genera el archivo OWL que almacena en su

almacn de informacin semntica. Adems de almacenarlo lo transfiere
tambin al gestor de publicacin DHT, que convierte el archivo OWL en
valores a almacenar en la tabla dinmica distribuida de la DHT Semntica.
En este caso se introducen como claves (K1,K2,.., Kn) las distintas
funciones hash de las URIs de los elementos descritos en el archiv OWL.
Como valor de la publicacin (V) se ofrece la direccin URL que permita
localizar el archivo OWL por parte de los distintos agentes. En la DHT
Semntica ha de indicarse a su vez si el par (clave, valor) se refiere a
informacin ABox o TBox.
Por otro lado, los agentes consultan en la DHT Semntica localizaciones de

archivos OWL donde se describa un elemento ontolgico determinado. Para
realizar esta funcin, el agente ha de consultar a la DHT Semntica
utilizando como clave de bsqueda la funcin hash de la URI que identifica
a nuestro elemento ontolgico (como puede ser el nombre de una clase) y si
la informacin que buscamos es para la TBox o para la ABox de la base de
conocimiento del agente. Tras esa peticin, la DHT semntica le contesta
con el valor V (o valores) que consiste en la URL del archivo OWL (o
archivos OWL) donde puede localizar esa informacin.
Una vez el agente ha obtenido la direccin URL donde localizar el fichero

OWL, intentar obtener dicho fichero de esa direccin. Para servir el fichero
OWL, el publicador dispone de un distribuidor de contenidos semnticos,
que obtiene del almacn el archivo que se ha solicitado. La razn por la que
no se sirve el fichero OWL directamente y se pasa por un distribuidor de
contenidos semnticos radica en que el almacn de informacin semntica
puede no ser un simple almacn de ficheros OWL, sino una base de
conocimiento que realice chequeos de consistencia de la informacin
ofrecida y actualice la informacin segn se la vaya ofreciendo el extractor
de informacin semntica.
Una vez descrito el proceso de localizacin y obtencin de informacin

semntica para los agentes inteligentes, pasamos a describir el
funcionamiento de la arquitectura de distribucin de contenidos.
5.5.2 Descripcin del funcionamiento de la arquitectura

Nuestro objetivo en este apartado es describir cmo debe funcionar todo el
sistema para permitir a los agentes la localizacin por medio de informacin
semntica de objetos educativos a compartir. Como ya hemos visto en otros
170
captulos, la web semntica se basa principalmente en describir URIs y

relacionarlas entre s por medio de propiedades
Las fases que definimos son las siguientes, que describiremos a fondo en los
siguientes subapartados:
1. Fase de definicin y creacin de ontologa a utilizar. En esta fase

los agentes absorben la informacin ontolgica bsica (entendida
como la informacin para su TBox). En el caso que ya tenga
informacin, intentar ampliarla por si hay ampliaciones
ontolgicas.
2. Fase de formacin de las queries ontolgicas. En este punto el

agente interacta con el usuario y le muestra las distintas
posibilidades de bsqueda de las que dispone.
3. Fase de inferencias de bsqueda, donde el agente utilizar su

informacin y obtendr ms informacin para su ABox para poder
localizar elementos que cumplan las restricciones impuestas por el
usuario.
4. Fase de contacto con el servidor de contenidos educativos. En

este punto el agente pide ms informacin al servidor de contenidos
para presentarlos al usuario y que negocie con el servidor si desea o
no descargar los objetos educativos relacionados.
5. Fase de descarga, donde se obtiene el objeto u objetos deseados.
Como podemos apreciar, estas fases engloban todas las acciones necesarias
para poder localizar y descargar los objetos educativos que necesite un
usuario para poder componer una experiencia educativa que pueda ser
utilizada por l mismo o por un conjunto de alumnos.
5.5.2.1 Fase de definicin y creacin de la ontologa a utilizar

En esta fase el usuario elige una URI donde se encuentra la parte principal
ontologa sobre la que realizar la bsqueda. Un ejemplo de URI de una
ontologa puede ser http://dcom.upv.es/owl/rorollo/tesis.owl#", que ser la
ontologa propuesta en esta Tesis y desarrollada para describir una
experiencia educativa.
171
Al usuario se le deberan presentar las ltimas ontologas utilizadas o

permitirle introducir la URI de la ontologa a mano. Esta parte podra quedar
eliminada si obligamos que siempre parta de la misma ontologa, facilitando
el uso pero limitando las posibilidades de realizar las mismas bsquedas
pero con otras URIs.
El agente utiliza el arranque de la bsqueda (que en principio ser el archivo

.owl con la descripcin de la ontologa en la versin inicial). Sin embargo,
OWL, como la mayora de los lenguajes ontolgicos de la red semntica,
permite que la definicin de la ontologa se encuentre distribuida en
distintos documentos, por lo que har es buscar en la DHT semntica los
documentos que se relacionan con la URI de definicin, y que no se refieren
exclusivamente a definir instancias de la ontologa.
El agente obtiene la ontologa por medio de localizar los ficheros que

definen la ontologa <owl:Ontology rdf:about="(la URI)"> y estn
marcados como TBox en la DHT Semntica. Adems, si encuentra
etiquetas de importacin de ontologas owl (<owl:imports
rdf:resource="(NEW_URI)>) continua aadiendo a su TBox la
informacin de la NEW_URI encontrada. Si encuentra ontologas ms
modernas que la que se busca (es decir, que referencian a nuestra URI en
<owl:priorversion>), debera indicarlo al usuario por si decide utilizar la
nueva versin de la ontologa (en caso de ser compatible con la anterior por
medio de <owl:backwardCompatibleWith> ). Este sistema es parecido al
definido para RDF en [BID04].
Cada vez que el agente aade informacin semntica de un fichero OWL a

su TBox, debe comprobar la congruencia del sistema para evitar que la
TBox contenga contradicciones. En principio una ontologa que se publique
en la DHT Semntica no debera contener contradicciones, pero se ha de
evitar realizar inferencias sobre ontologas inconsistentes, ya que pueden
llevarnos a resultados dispares.
Tras esta fase el agente ya ha almacenado en su TBox la informacin bsica

de la ontologa: definicin de clases y propiedades, lo que denominaremos
la ontologa bases (a falta de incluir instancias de las clases).
5.5.2.2 Fase de formacin de las queries ontolgicas

Una vez almacenada la ontologa base, el agente presenta al usuario las
posibilidades de bsqueda que se presentan, que depender de las clases y
propiedades que se han encontrado.
172
Pongamos por ejemplo la ontologa definida en esta Tesis para la

teleformacin (http://dcom.upv.es/owl/rorollo/tesis.owl#). El agente le
presentar al usuario la posibilidad de buscar foros que cumplan ciertas
condiciones. Una de las posibilidades de bsqueda sera buscar las
instancias de la clase LearningExperience que contengan instancias de
ForumThread cuyo hasFirstTreeItem contenga la palabra Socket en el
String que devuelve su propiedad getText. Estas clases ontolgicas se vern
en el siguiente captulo de esta Tesis.
Para aplicaciones especficas con TBoxes fijas, el usuario puede pasar

directamente a realizar unas ciertas bsquedas predefinidas que facilitan las
tareas de bsqueda. De todas formas esto hara perder parte de la
flexibilidad del uso de la web semntica y pasara a ser un sistema
predefinido basado en XML o en RDF.
Al final de esta fase el usuario decide el tipo de bsqueda que desea realizar,
y ordena al agente que comience la bsqueda en la web semntica, es decir,
basndose en su TBox ampliar la ABox con instancias e ir realizando
inferencias hasta encontrar elementos que cumplan los requisitos de la
bsqueda planteada.
5.5.2.3 Fase de inferencias de bsqueda

En esta fase el agente realiza las inferencias necesarias y decide qu tipos
de instancias de qu clases ha de buscar. Su primera accin es asegurarse
que la bsqueda que pedimos no es incongruente segn su base de datos,
para detener la bsqueda en ese caso.
Empieza la bsqueda obteniendo informacin para la ABox de la DHT

semntica. De la DHT obtiene la localizacin de los archivos .owl a
descargar del servidor de contenidos, no volviendo a descargar un fichero si
ya lo ha obtenido, ya que se le supone un cacheo de ficheros obtenidos.
Como las DHT slo permiten bsquedas por palabras exactas, en caso de
filtrar por partes de palabras de un campo, debe ser el propio agente en el
momento de obtener las fuentes, generando internamente una subclase de la
clase a filtrar y poblndola con las instancias que cumplan la restriccin. Por
ejemplo, en la bsqueda de la fase anterior, debera buscar instancias de la
clase FirstTreeITem y generar una subclase que se poblara con las
instancias de FirstTreeItem que contuvieran el subString Socket en su
propiedad getText.
173
5.5.2.4 Fase de contacto con el servidor de contenidos educativos

El agente va encontrando resultados, y se los muestra al usuario, junto con
la informacin del recurso que ha encontrado. Hasta este punto el agente ha
servido como un buscador semntico, es decir, ha ido poblando su base de
conocimiento y realizando inferencias sobre la misma para poder devolver
instancias que cumplan los requisitos exigidos por el usuario. Hasta aqu
llega la bsqueda en la web semntica.
El usuario decide si quiere obtener ms informacin de ese recurso

educativo, y si lo hace se accede al servidor que contiene esa fuente (un
servidor de objetos educativos). El agente entonces pedir al servidor de
objetos educativos toda la metainformacin sobre ese objeto educativo. En
este caso el Servidor puede ofrecer solamente la informacin en owl que ya
ha ofrecido en el periodo de bsqueda o puede ensear demostraciones, que
permitan conocer ms el objeto, siendo esta parte ms publicitaria y dirigida
a ser entendida por el usuario directamente.
Como vemos esta parte es ms comercial, ya que se ha localizado algn

objeto educativo de los que busco pero ha de ser el usuario quien realice la
validacin final y negociacin para decidir si adquiere o no el objeto
educativo.
5.5.2.5 Fase de descarga

Cuando el usuario, que normalmente ser un ensamblador de contenidos,
est interesado en alguno de los objetos, pasar a pedir la obtencin del
contenido del objeto educativo. En este caso se especifica un sistema de
entrega de contenidos inteligente de forma que el servidor de contenidos
pueda servir directamente al cliente o, si detecta que va a servir un archivo
grande (normalmente los que tienen una gran carga multimedia), pase a
ejecucin del protocolo de distribucin BitTorrent, arrancndolo por medio
de envo del archivo .torrent al agente que espera la descarga.
En este segundo caso el agente que pasa a la descarga, debe estar preparado
para ejecutar el protocolo BitTorrent si est obtenido en obtener la
informacin.
5.5.3 Elementos del sistema

Los nodos mnimos existentes en el sistema para que se realice un
funcionamiento normal de la arquitectura sern (ver figura 5.5):
174
Los servidores de objetos educativos (servidores de contenidos).

En este caso se supone que son repositorios en entidades que decidan
entrar a compartir contenidos, por lo que son sistemas ya existentes.
Estarn distribuidos por distintas entidades productoras de
contenidos educativos (universidades, empresas, colegios, etc). Se
define el sistema con servidores dedicados a la distribucin de estos
contenidos que estn activos y conectados al sistema la mayora del
tiempo, lo cual se cumplir por el propio inters de las entidades que
ofrecen los contenidos.
No se especifica una estructura P2P entre las distintas entidades que

tuviera como objetivo compartir las tareas de descarga de objetos
educativos, ya que estas entidades pueden ser competidoras y no es
muy probable que servidores ms potentes y con mejores conexiones
cedan recursos a otras entidades competidoras que han invertido
menos en recursos.
Sin embargo, como hemos comentado en la descripcin del

funcionamiento, s que se genera una estructura P2P BitTorrent-
entre el servidor de contenidos y los agentes que estn
descargndose un fichero grande. Se especifica que slo se ofrezca al
agente el documento .torrent cuando est ya permitido el acceso a los
contenidos (por ejemplo, cuando haya aceptado el pago por el
contenido).
Los servidores de bsqueda semntica (superpeer semnticos)

Estos servidores permitirn buscar contenido semntico para
alimentar las TBoxes y Aboxes de los agentes inteligentes de
bsqueda. El espacio de identificadores posible se define de 128 bits
como en la red Kad que usa el eMule.
El sistema tendr un conjunto de servidores dedicados a mantener la

DHT semntica (al menos para dar una mnima capacidad), aunque
puede que sean servidores virtuales ofrecidos por cada uno de los
servidores fsicos de contenidos, ya que en este caso s que estn
todos interesados en mejorar la red de bsqueda de contenidos.
175
Fig. 5.5. Elementos del sistema
Como vemos en la figura 5.5, los servidores de contenidos, por medio de su

publicador semntico, publicarn a la DHT Semntica su informacin, que
buscarn los agentes de los usuarios para localizar objetos educativos en los
que estn interesados. Cuando el usuario elige un objeto educativo, se
contacta directamente con el servidor de contenidos que lo ofrece, para
poder verlo con ms detalle y descargarlo si as lo consideran ambas partes
(el usuario consumidor y el servidor de contenidos).
5.5.4 Escalabilidad de la arquitectura

En este apartado definiremos los distintos mecanismos que defendern a la
arquitectura definida frente a los grandes aumentos de tamao, tanto a nivel
de informacin semntica que se guarda en la DHT Semntica como a nivel
176
de grandes demandas de descarga de un mismo archivo. En estos aspectos

ser donde veremos las ventajas de una arquitectura P2P cuando hay
grandes variaciones de necesidad de recursos.
5.5.4.1 Escalabilidad respecto a la DHT Semntica

Como hemos comentado, la arquitectura se basa en unos superpeers
semnticos dedicados que aseguran un mnimo de servicio en el arranque de
la DHT Semntica.
La escalabilidad se ve comprometida por dos causas principales:
Aumento desmesurado de los contenidos a indexar en la DHT

Semntica. En este caso, para aumentar la potencia a la vez que se
aumentan contenidos se define el comportamiento de los nodos de
forma que cuando un nodo se encuentre saturado, obligue a alguno
de los servidores de contenidos a los que indexa -cuyas direcciones
tiene como valores de las claves que controla- a que entre a
participar en la red de bsqueda con un servidor de bsqueda virtual.
Si se niega, libera (borra) sus entradas y si ya es servidor de
bsqueda busca el siguiente.
Este nuevo nodo virtual para la DHT entrar con un valor de hash
tambin virtual, de forma que se site topogrficamente al lado del
nodo saturado y pueda as descargarlo. Es muy poco probable que
aparezca un nodo con un valor de hash de su direccin igual al de
nuestro nodo virtual, pero en ese caso el servidor virtual se dara de
baja automticamente a s mismo.
Es importante destacar que por cada fichero .owl que publiquemos,

generaremos n entradas en la DHT Semntica. Sobre un estudio de
ms de 14.000 documentos RDF, se han encontrado una media de 65
aserciones por documento (una asercin tiene tres URIs, los dos
recursos que relaciona y la propia relacin), lo que nos da 65*3 URIs
por documento [BID04], con lo que podemos suponer que la
cantidad de entradas en la DHT Semntica unos dos rdenes de
magnitud superior al nmero de documentos que indexa.
Aumento desmesurado de las peticiones de bsqueda. Este caso

se da cuando muchos agentes inteligentes atacan a la DHT
Semntica. Para absorber los picos de peticiones, se define un
mecanismo parecido al anterior, pero en dos fases, consistiendo la
177
primera fase en obligar a los servidores de contenidos a realizar

funciones de servidores virtuales de bsqueda.
En una segunda fase, si sigue habiendo saturacin, se obliga a los

propios agentes de bsqueda que estn realizando bsquedas a que
cedan recursos a modo de nodo de bsqueda en la red, siendo estos
nodos muy voltiles que desaparecern al poco tiempo de realizar las
bsquedas completas.
Para realizar de forma distribuida este segundo control de saturacin,

especificamos que cuando un Servidor de bsqueda detecte que est
saturndose para servir todas las peticiones que le llegan, marque
todas sus respuestas con una peticin de colaboracin (como si
mandara un SOS con la respuesta).
Cuando un agente detecte una marca de peticin de colaboracin, ha

de agregarse como servidor de bsqueda. El nodo que le ha servido
la ltima bsqueda (por el que accede el agente de bsqueda) slo
aceptar de l una peticin de unin a la red DHT Semntica hasta
que se integre en la misma, no permitindole ninguna otra bsqueda
hasta que sea un miembro de la DHT Semntica.
Algunos autores [TRA03] indican que la aparicin de nuevos nodos,

si son voltiles, cargan ms la red que el beneficio que generan. Para
evitar esto se le exige al agente a permanecer ofreciendo servicios de
bsqueda durante una hora consecutiva.
Por lo tanto, el sistema de bsqueda semntica (la DHT Semntica) se

protege ante los picos de demanda de recursos, basndose en algoritmos
similares a los de otras redes P2P, en las que empiezan a colaborar primero
los servidores de contenidos (al ser ms estables y confiables) y en ltima
instancia los propios nodos de los usuarios.
5.5.4.2 Escalabilidad respecto a la distribucin de contenidos

En este apartado nos referimos a las herramientas que evitan la saturacin
del sistema a la hora de distribuir los contenidos educativos.
Segn nuestra arquitectura, sern los propios servidores de contenidos los

que decidan cul de las dos maneras de distribucin prefieren, en funcin
del tamao de la fuente:
178
Para distribucin de ficheros pequeos, se servirn de forma normal

va HTTP, por una sencilla arquitectura cliente-servidor
Para ficheros grandes, para evitar una posible congestin si se piden

el mismo fichero por parte de muchos agentes, se pasa a la
distribucin BitTorrent, generando una especie de subred entre el
servidor de contenidos y los agentes como indica la figura 5.6, donde
se ve con colores cada uno de las partes del archivo general y cmo
fluyen esas partes entre algunos nodos que no son el servidor.
179
Fig. 5.6. Subred BitTorrent
En la figura 5.6 podemos ver como un objeto educativo de gran tamao, se

divide en paquetes (en este caso [A,B,C,D,E]). El servidor de contenidos va
distribuyendo paquetes del objeto, y a su vez cada nodo que se descarga un
paquete ha de estar dispuesto a ofrecerlo a otros nodos que lo necesiten. En
180
este caso, podemos ver como el nodo 1 contiene los paquetes [A,B,C], y en
este instante est sirviendo el paquete A a los nodos 2 y 4 y el paquete C a
los nodos 2 y 3. A su vez en este instante est recibiendo el paquete D del
servidor de contenidos y el paquete E del nodo 2. Los nodos 2 y 3 estn
tambin ofreciendo los paquetes que contienen y recibiendo los paquetes
que le faltan en este momento. El nodo 4 es un nodo recin incorporado que
no tiene an paquetes para ofrecer y est recibiendo el primer paquete. En el
ejemplo queda patente que los paquetes no tienen por qu servirse y
recibirse en orden y que es beneficioso que varios nodos reciban paquetes
complementarios para luego poder compartirlos entre ellos y descargar al
nodo servidor. Como vemos la figura 5.6, al tener cada nodo paquetes
distintos los pueden compartir con mayor facilidad. Menos el nodo 4, que
acaba de conectarse, todos los otros nodos estn ya recibiendo todos los
paquetes que les faltan, mientras ningn nodo incluyendo al servidor- est
sirviendo ms de 4 paquetes.
Como indica el protocolo de BitTorrent, cuando un agente termina de

descargarse un archivo ha de mantenerse en la red durante un tiempo para
seguir colaborando en la distribucin de contenidos. En nuestra arquitectura
en particular, es el propio servidor del fichero (seed) el que ofrece el fichero
.torrent para comenzar la descarga, no existiendo servidores que ofrecen
ficheros .seed de forma exclusiva.
5.5.5 Aspectos de seguridad de la arquitectura

Como ya hemos visto uno de los puntos crticos de las arquitecturas P2P, es
el de la seguridad, ya que no existe control sobre los nodos por los que
pasan los datos, quin los pide realmente ni hay un sistema de control
centralizado.
Los aspectos principales a tratar son:
Confidencialidad, es decir, que toda la informacin que enve el

servidor de contenidos le llegue al agente de destino y slo a l.
Como no tenemos control sobre la red al ser Peer to Peer, la solucin
propuesta consiste en un sistema de cifrado de clave pblica/privada,
de forma que cuando el agente solicite el fichero incluya a su vez su
clave pblica para que slo el agente destino pueda leer el contenido.
Este procedimiento no es directo en el caso de BitTorrent, ya que el

archivo va dirigido a muchos agentes. Para resolver este punto, se
realizar un sistema de cifrado de clave pblica/privada para cada
181
descarga de cada paquete de un nodo a otro, ya que cada paquete

puede proveer de cualquier nodo del enjambre que lo tenga
disponible. Para realizar esta accin, en el protocolo de solicitud de
un paquete a uno de los nodos del enjambre de descarga, se enviar
la clave pblica del receptor. El emisor contestar con el paquete
codificado con la clave pblica del receptor, de modo que slo podr
descifrarlo el receptor con su clave privada.
Autentificacin, de forma que sepamos que quien nos enva una

informacin es realmente quien dice ser. Para resolver esto
utilizaremos autentificaciones como las definidas en la arquitectura
JXTA, es decir, un sistema de autentificacin SSL o equivalentes
(STL o IPSec).
Integridad de los datos, resuelto por medio de una firma de los

datos encriptados enviados, de forma que podamos conocer si son
los datos originales o se han corrompido.
Autorizacin, de forma que slo los nodos que tienen en cada caso
permitida una funcin la realicen. Para resolver esta situacin nos
basamos en el escaso inters de nodos ajenos a ceder sus recursos
para estas redes, as como en el sistema de proteccin contra boicots
del punto siguiente.
Proteccin contra boicots e usos indebidos. Nos referimos en este

apartado a la proteccin frente a nodos que sobrecargan la red o que
envan mensajes falsos, de forma que consumen recursos de la
misma para un fin distinto al proyectado. Para resolver este
problema definimos un protocolo de lista negra, de forma que slo
los nodos fiables puedan publicar en la lista y que no se permita la
entrada a agentes que estn en la lista negra. En este caso los nodos
que pueden ser fiables sern todos los nodos que no sean agentes, ya
que se les supone de mayor confianza.
Para evitar la centralizacin de la lista negra, se define un sistema

distribuido de confianza, de modo que cuando un nodo detecte a otro
malicioso, se lo apunte en su lista y lo publique a sus nodos
conectados directamente (en la DHT semntica se considera que los
nodos a los que est un nodo conectado son los que tiene en sus
buckets). Un nodo slo aceptar informacin para actualizar su lista
negra de nodos en los que confa (por ejemplo, nodos que han estado
182
funcionando bien durante bastante tiempo). Adems, slo marcar

un nodo como malicioso cuando reciba ms de una notificacin
proveniente de distintos nodos en los que se confa.
5.6 Conclusiones
En este captulo se ha presentado una arquitectura que nos permite que los
agentes inteligentes puedan buscar la informacin semntica necesaria para
encontrar fuentes de objetos educativos, as como descargarlos de los
servidores de contenidos correspondientes.
Un punto importante a destacar en esta arquitectura es que funciona sobre

cualquier otro tipo de ontologa, ya sean educativa o de otro tipo, sin
modificar ninguna parte de la misma. Incluso puede dar servicio a la
distribucin de otros tipos de contenidos con metainformacin en forma
semntica. Adems, la DHT Semntica que hemos definido en este captulo
nos permite realizar la publicacin y explotacin de contenidos semnticos
por parte de agentes inteligentes de cualquier ontologa, sea educativa o no,
implementan una gigantesca base de conocimiento distribuida en la propia
DHT Semntica, a la que consultan los agentes para localizar fragmentos
OWL de la misma.
Al describir la arquitectura, se ha realizado a su vez una descripcin

funcional de la misma, indicando los mecanismos para conseguir gran
escalabilidad y los aspectos relacionados con la seguridad necesarios para
un funcionamiento correcto de una red P2P como la que planteamos en este
captulo.
Se ha mostrado tambin que, por la naturaleza de los contenidos a distribuir

-normalmente con derechos de autor, de tamao muy variable, y adems,
actualizables por los servidores de contenidos- es ms aconsejable que se
almacenan los objetos educativos y los ficheros OWL en los mismos
servidores de contenidos, no realizando un almacenaje completamente
distribuido en la red. Por tanto la arquitectura es Peer to Peer respecto a la
localizacin de informacin semntica y respecto a la descarga de grandes
ficheros por varios agentes, pero no en las tareas de almacenamiento de los
objetos educativos.
Sin embargo hay una parte importante para que funcione correctamente una
red P2P: el inters de los nodos en participar de forma interesada o
desinteresada en la red. Es por esto que en caso de ser necesario se solicitan
recursos a los servidores de contenidos, ya que son ellos los primeros
183
interesados en promocionar sus productos. En caso de no ser suficiente

dicha colaboracin, se solicitan recursos despus a los agentes de bsqueda,
puesto que ellos estn interesados en el servicio que les ofrece la red.
.
184
Captulo 6. Especificacin de Ontologa para Interoperabilidad
Captulo 6: Especificacin de
Ontologa para
Interoperabilidad
6.1 Introduccin
A lo largo de este captulo se definir en profundidad y de forma rigurosa la
ontologa que permite la interoperabilidad de las experiencias educativas en
mejores condiciones que mediante el uso de las ontologas actualmente
existentes.
El objetivo de esta ontologa es permitir al usuario un acceso eficaz, rpido,

organizado, fcil y completo a las experiencias educativas disponibles, para
obtener resultados ajustados, precisos y clasificados para ser incorporados y
reutilizados con otros fines educativos distintos de los previstos
inicialmente.
185
En este sentido, el proceso permite al usuario determinar mejor las

bsquedas que desea realizar, y ajustar con ms precisin los resultados que
desea obtener, gracias a la utilizacin de criterios ontolgicos especficos.
Adems, el proceso se puede realizar de forma rpida ya que el uso de

ontologas en la web semntica permite que sean los agentes inteligentes los
que realicen las bsquedas y filtrados previos, para presentar al usuario los
resultados ms relevantes de forma automtica.
Otra de las ventajas de este sistema es que permite el acceso a informacin

de las experiencias educativas a las que hasta el momento no era posible
acceder a travs de las ontologas existentes. Nos referimos, por ejemplo, a
la posibilidad de acceder a las interacciones entre los distintos actores de un
proceso formativo como pueden ser los foros, lo que supone tambin un
aspecto novedoso de esta especificacin.
La ontologa implementada permite tambin organizar los resultados de las

bsquedas realizadas, de forma que se pueden agrupar las soluciones bajo
una serie de criterios especficos predeterminados que el usuario puede
elegir. Por ejemplo, si se realiza una bsqueda de objetos educativos que
traten sobre la temtica computacin paralela los agentes podrn presentar
resultados agrupados en cursos especficos de computacin paralela, cursos
en los que los usuarios realizan comentarios sobre computacin paralela, y
cursos en los que se realizan preguntas sobre computacin paralela, entre
otros. Esta organizacin de los resultados facilita la obtencin de una visin
clara del material disponible, lo que permite una mejor y ms rpida
planificacin del trabajo a realizar.
Asimismo, esta ontologa se caracteriza porque la intermediacin de agentes

inteligentes en bsquedas muy especficas reduce la posibilidad de olvidar
una fuente, ya que los agentes realizan bsquedas ms exhaustivas que las
que pueda realizar un usuario, lo que evita que el usuario tenga que definir
cada una de las fuentes en las que est interesado. Puede ocurrir que el
usuario no estuviera inicialmente interesado en obtener informacin sobre
una experiencia educativa en concreto o no hubiera evaluado correctamente
su posible utilidad, pero al obtener un resultado sobre sta descubra que
tambin puede servir para sus objetivos. De esta forma, la ontologa
propuesta aprovecha las posibilidades de la Web Semntica, ya que est
basada en un leguaje OWL, que se caracteriza por su idoneidad este
contexto.
186
La implementacin de esta ontologa est basada en estndares y modelos

de referencia que gozan de una amplia aceptacin, como son los
desarrollados por IEEE, ADL e IMS. Esta caracterstica facilita el uso de la
ontologa a usuarios familiarizados con el uso de estos sistemas, pues
permite ganar rapidez en las bsquedas al utilizar conceptos ya conocidos. A
su vez, facilita la generacin de metainformacin para ser publicada,
siguiendo la ontologa propuesta en esta Tesis.
Para la especificacin de la ontologa se seguirn las pautas metodolgicas

indicadas en [NOY01][REC05]. De esta manera, se enumeran los distintos
conceptos que son objeto de estudio, luego se agrupan por similitud y
utilidad y, por ltimo se realiza una especificacin formal de los mismos
que permita traduccin directa a un lenguaje ontolgico, como puede ser
OWL.
Fruto de esta metodologa, presentaremos primero una ontologa general

para Teleeducacin, que se dividir en tres ontologas diferenciadas. La
primera de las ontologas tratar la conceptualizacin de los contenidos
estticos. La segunda de las ontologas versar sobre las interacciones del
alumno con el sistema, por medio de las evaluaciones. La tercera y ms
novedosa ontologa se centrar en las interacciones entre los usuarios
(basado en una visin constructivista del aprendizaje), escogiendo en este
caso los foros, ya que son, junto con el correo electrnico, uno de los
elementos ms utilizados para estas interacciones. Los foros son, adems, un
campo no tratado hasta el momento dentro de las ontologas para la
interoperabilidad.
La posibilidad de compartir la informacin introducida a travs de la

interaccin de los usuarios es interesante y til para generar una base de
conocimiento que podramos aprovechar en otras imparticiones del curso.
De esta forma podemos ir enriqueciendo nuestro repositorio de experiencias
educativas con las impresiones descritas en los foros. Esto nos permitir
ampliar las bsquedas, ya que se podr buscar entre todas las interacciones
de los foros, para dar con una informacin especfica o para elegir qu
objeto educativo reutilizar.
El procedimiento que se va a seguir para realizar la especificacin, una vez

identificadas las tres ontologas, es el siguiente: en primer lugar se
analizarn los conceptos de cada una de las tres ontologas Una vez se han
definido los conceptos y antes de pasar a especificar las ontologas, se ha
187
considerado conveniente introducir un elemento auxiliar que permita

especificar las estructuras en rbol y que se utilizar en las especificaciones
siguientes. A continuacin se realizar una especificacin formal para cada
una de las ontologas. Finalmente, se especificarn los nexos de unin entre
las tres ontologas descritas.
6.2 Visin General

La especificacin general la separaremos en tres ontologas (ver Fig. 6.1):
Ontologa para los contenidos estticos, donde se indique su

estructura.
Ontologa de la de la interaccin del alumno con alguno de los

contenidos. Nos referimos en este punto a las evaluaciones, sean del
tipo que sean.
Ontologa de descripcin de las interacciones entre usuarios. Esta

ontologa ser la que proporcione la visin constructivista a nuestra
ontologa general.
Desarrollaremos las tres ontologas en este captulo, realizando primero las

definiciones de los conceptos de cada una de ellas y luego realizando la
especificacin formal con el lenguaje de lgica descriptiva que nos servir
para poder plasmarla en OWL.
Fig. 6.1. Descripcin de la ontologa General
Como se indica en la figura 6.1, las tres ontologas que forman la ontologa
general se relacionan entre s, utilizando la ontologa de contenidos estticos
como puente para conectar las interacciones alumnos-sistema y las
188
interacciones entre los usuarios. Tambin se indica en la figura que las

interacciones alumno-sistema sern las que apoyen un aprendizaje segn las
teoras conductistas, ya que premian un comportamiento del alumno. El
comportamiento que se premiar ser en este caso la realizacin de una
prueba o test, que servir para determinar si han alcanzado los objetivos de
aprendizaje. Por otro lado, se muestra que las interacciones entre usuarios
pretenden apoyar el aprendizaje por medio de un enfoque constructivista, en
el que por medio de la relacin de un alumno con otros miembros de la
experiencia educativa se produce tambin un aprendizaje. Por ltimo,
aunque no siempre ser as y depender de los contenidos en s, podemos
considerar que los contenidos estticos pretenden fomentar el aprendizaje
por medio de definiciones de conceptos y relaciones entre los mismos, por
lo que es esta ontologa la que permite el aprendizaje por medio de teoras
cognoscitivistas. En esta Tesis se considera que el aprendizaje se produce
por medio de las tres formas anteriormente indicadas, y es por esto que se
desarrollan las tres ontologas agrupndolas en una general.
6.2.1 Ontologa para los contenidos estticos

Entendemos como contenidos estticos a los contenidos que han sido
creados antes de la fase de imparticin del curso y no generan informacin
sobre la adquisicin de conocimientos por parte del alumnos ms all de la
comunicacin al sistema de la navegacin del discente por los contenidos.
Incluye desde las pginas html donde se describen los apuntes del curso
hasta los documentos multimedia donde al alumno puede observar ejemplos
reales (por ejemplo, por medio de vdeos) o representaciones. Todos estos
contenidos se podran almacenar directamente en un CD y enviarlos en este
formato a los potenciales alumnos.
La ontologa de contenidos estticos es un tipo de ontologa muy

desarrollada por gran cantidad de autores, siendo las ms aceptadas y
extendidas IMS Content Packaging Specification [IMS04] y SCORM
Content Aggregation Model (basado a su vez en IMS CP) [ADL04a]. De
hecho, la mayora de plataformas (como Moodle) aceptan paquetes SCORM
o IMS. Algunas de las herramientas de autor y sistemas propietarios estn
dirigiendo sus esfuerzos para poder trabajar con alguno de los dos
estndares a nivel de contenidos estticos [BAR04], [ROM06]. De hecho,
las ontologas arriba mencionadas son ontologas implcitas, entendiendo
implcitas como ontologas no plasmadas en un lenguaje ontolgico para la
web como OWL, por lo que dicha ontologa se ha de programar
previamente en los distintos agentes que utilizan los datos. Tambin existen
actualmente otros desarrollos de ontologas de contenidos estticos ya
189
implementados en lenguaje OWL para sus metadatos

[SAN05][GUO06][ULL04]. Sin embargo, los desarrollos actuales de
ontologas sobre contenidos estticos son desarrollos en los que se abarcan
conceptos parciales, como puede ser la implementacin parcial de IEEE-
LOM de [SAN05] o la enumeracin de distintos tipos de actividades
instruccionales de [ULL04]. La ontologa en OWL sobre educacin ms
completa sobre los contenidos estticos la encontramos en [GU06], donde se
distingue entre la ontologa de la materia que se trata, la ontologa sobre el
contexto o tipo de actividad instruccional y por ltimo la ontologa sobre la
estructura de los contenidos, pero sin seguir en ningn caso las pautas
marcadas por IMS CP o SCORM.
Si bien existen ejemplos de traducciones parciales de SCORM en OWL

(usando OWL-S[ARO04] o una versin OWL del lenguaje
DyLOG[BAL04]), se ha preferido realizar una implementacin propia para
simplificar el modelo debido que no trataremos la ontologa para definir la
secuenciacin y navegabilidad de los contenidos. La razn por la que no se
incluyen estos aspectos en la ontologa es la poca utilidad que puede aportar
la inclusin de esta informacin para realizar bsquedas de recursos
educativos que podamos compartir. Los aspectos de navegabilidad y
secuenciacin s son tratados en las ontologas comentadas
anteriormente[ARO04], [BAL04], siendo de hecho la parte de SCORM
implementada. Tanto en [ARO04] como en [BAL04] se conceptualiza cada
actividad de aprendizaje como un proceso de servicio web. Dicho proceso es
compuesto y descrito por algn lenguaje descriptivo de procesos como
puede ser OWL-S, que nos indica los distintos subprocesos de aprendizaje
por donde va pasando la actividad de aprendizaje global.
Por estas razones se decide en esta Tesis generar una ontologa nueva para
los contenidos estticos basada en estndares e implementaciones de
referencia globalmente reconocidos. En el desarrollo que especificaremos
nos basaremos en el modelo de referencia SCORM. Para definir la ontologa
basada en SCORM podramos habernos basado en la versin XML de
SCORM tal como aparece en el modelo de referencia y transformar los
objetos de XML en clases de OWL, de forma que nuestra ontologa fuera
una simple enumeracin de clases y subclases sin restricciones definidas
explcitamente. Sin embargo, en esta Tesis se opta por ampliar ms la
ontologa por medio de la introduccin de las restricciones principales del
modelo de referencia en la descripcin OWL. Cuanto ms relaciones entre
instancias y axiomas traslademos a nuestro lenguaje ontolgico, ms til va
a ser ya que son estas restricciones las que van a entender los agentes
190
inteligentes cuando realicen bsquedas. Por ejemplo, si por medio de

relaciones y axiomas somos capaces de describir una estructura en rbol
entre los elementos, podremos realizar bsquedas en las que indiquemos que
nos devuelva el objeto raz de un rbol que contenga otro elemento en su
interior que cumpla unos requisitos que le impongamos. Como podemos
apreciar, son estos tipos de relaciones y axiomas los que permiten realizar
bsquedas ms inteligentes que una simple bsqueda en documentos XML,
y por tanto uno de los puntos ms novedosos del uso de lenguajes
ontolgicos. No tendra sentido utilizar lenguajes ontolgicos slo para
enumerar objetos y caractersticas de los mismos que podra realizar con
lenguajes de ms bajo nivel como puedan ser XML o RDF.
Para comenzar la definicin de nuestra ontologa abstraeremos los

contenidos estticos en la siguiente estructura:
Learning Content Package . Es el elemento que abstrae la

informacin relativa a un paquete exportable SCORM. Podemos
decir que la clase equivale a la abstraccin del la etiqueta
<imscp:manifest> de la representacin XML de SCORM.
Organization. En cada instancia de la clase Learning Content

Package existe al menos una instancia de la clase Organization, que
indica las diferentes organizaciones de los contenidos de paquete
segn el contexto al que se dediquen. De este modo, existir una
relacin de un objeto Learning Content Package con un objeto
Organization por cada forma distinta de presentar los contenidos.
Por ejemplo, un paquete de un curso sobre matemticas puede tener
todos sus recursos en una organizacin que formacin integral y slo
los avanzados en una formacin integral pero para estudiantes con
conocimientos en la materia. Su equivalencia con la etiqueta XML
<imscp:organization> de SCORM es directa. A partir de l aparece
una estructura jerrquica de rbol.
Learning Activity. Es el equivalente a una unidad de aprendizaje, y

permite una divisin en otras instancias de la clase Learning Activity
a n niveles. La etiqueta XML en la que se representa este concepto
en SCORM es <imscp:item>. Este concepto se basa en la suposicin
que indica que los contenidos educacionales on-line, estn generados
con la herramienta que sea, pueden representarse como un rbol de
contenidos de n niveles. Cada sistema tiene un conjunto distinto de
niveles. En la Tabla 6.1 podemos ver ejemplos.
191
Canadian US Marine US Army Buddha

Armed Forces Corps
Course Course Course Minicurso
Performance Phase Module Unidad de
Objective Aprendizaje
Enabling SubCourse Lesson Segmento
Objective (Annex)
Teaching Point Lesson Learning Pantgina
Objective
Task Learning Step
Contenido
Learning Recurso/Ampliacin
Objective
Learning Step
Tabla 6.1. Ejemplo de estructuras de contenidos de aprendizaje, con
distintos niveles [ADL04a]
Como indica la Tabla 6.1, los distintas estructuras de aprendizaje de

los distintas definiciones de contenidos de teleformacin se pueden
dividir en elementos repartidos en n niveles de una estructura en
rbol. Por ejemplo, la formacin de los cuerpos de Marina de
Estados Unidos utiliza contenidos estructurados en una estructura de
rbol a 7 niveles.
SCORM define una estructura de rbol sin fijar el nmero mximo

de niveles, pero distingue entre las actividades que contienen otras
actividades de aprendizaje (llamadas actividades de tipo Cluster) y
las actividades de aprendizaje que no contienen a otras actividades
(denominadas como actividades de tipo Leaf Activity). Una de las
restricciones que plantea SCORM es que slo las actividades Leaf
Activity puedan contener recursos educativos, mientras que las
actividades Cluster slo sirven a nivel lgico para realizar una
organizacin de los contenidos. Esta restriccin es necesaria en
SCORM para una correcta representacin de los contenidos en orden
en el Sequence & Navigation Model, y se respetar en esta ontologa
pese a no tratar la navegabilidad para mantener la mayor
compatibilidad entre SCORM y nuestra ontologa.
Resource (recurso) conceptualiza el archivo o archivos en los que se

puede dividir una experiencia educativa. En este caso
representaremos nuestro recurso por medio de la URI que lo
192
identifica de forma nica. SCORM diferencia entre objetos Resource

de tipo Assets y SCOs.
Un objeto Asset representa el recurso ms bsico. Son la forma ms

simple de recurso, y representa cualquier documento (texto, imagen,
sonido o cualquier otro tipo de dato) que puede ser representado
directamente por un cliente Web.
Por otro lado, un objeto Sharable Content Object (SCO)

conceptualiza tambin un recurso pero que realiza cierta
comunicacin entre l mismo y el LMS, en funcin de la interaccin
del usuario.
Como resumen de los descrito hasta este punto, hemos abstrado en cuatro
clases principales y cuatro subclases la ontologa de contenidos estticos.
Las denominaciones y definiciones se han realizado para que sean lo ms
similares al modelo de referencia SCORM, para permitir mayor
compatibilidad y facilitar la extraccin de la ontologa OWL de paquetes
SCORM ya existentes.
Como se ha descrito en este apartado, la estructura de los contenidos se basa

en una estructura en rbol. Al no existir predefinida la estructura de rbol en
OWL, se definir formalmente la abstraccin de una estructura en rbol para
aprovecharla en esta y otras ontologas.
6.2.2 Ontologa para las interacciones alumno-sistema

En este apartado trataremos de la ontologa para las interacciones alumno-
sistema, que conocemos como evaluaciones. Nos volveremos a basar a su
vez en el modelo propuesto por SCORM, en el que hay ciertas partes
(denominadas SCOs) que interactan con el sistema de gestin del
aprendizaje (LMS) para hacer un cierto seguimiento de los avances
formativos del alumno. Si bien existen algunas ontologas desarrolladas en
OWL [KIM05][ULL04] que incluyen en su ontologa las evaluaciones,
ninguna de las desarrolladas en este lenguaje ontolgico para la Web se basa
en IMSQTI, que es el estndar ms aceptado para implementar la
interoperabilidad de las evaluaciones.
Para definir la ontologa de las evaluaciones nos basaremos en el modelo de

referencia SCORM[ADL04c] y en IMSQTI [QTI06], de forma que
conceptualizaremos en clases los modelos de referencia. Como se realiza en
SCORM y en IMSQTI, separaremos la ontologa de resultados obtenidos
193
(basada principalmente en SCORM) de la ontologa de descripcin de las

actividades de evaluacin (que basaremos en IMSQTI). La relacin entre las
dos ontologas la podemos ver en la Fig. 6.2.
ACTIVIDADES A RESULTADOS A
REALIZAR OBTENER
Ayuda a la obtencin de parte

de / toda la competencia
Competence
LearningActivity
LA1
Consigue la obtencin del LearningObjective

LearningObjective LO1
AssessmentActivity
AA1
LearningObjective
LO2
AssessmentActivity
AA2
LearningObjective
LO3
Fig. 6.2. Relacin entre las ontologas de descripcin de actividades y de

resultados
Como se describe en la figura 6.2, tenemos por una parte unas actividades
que sirven para evaluar al alumno, que en caso de ser resueltas de forma
satisfactoria por parte del alumno evidenciarn que el alumno ha alcanzado
un objetivo de aprendizaje determinado. Si el alumno supera un conjunto
definido de actividades de evaluacin, que a su vez evidencia una obtencin
de un conjunto de objetivos de aprendizaje, podremos concluir que el
alumno ha obtenido una competencia determinada.
La descripcin en detalle de las actividades de evaluacin, que

representaremos por medio de la clase AssessmentActiviy, se basar en la
definicin del modelo de informacin de IMS QTI [IMSQTI] y en parte en
los tipos definidos por IEEE.1484.11.1 [IEEE05]. La parte de descripcin
de los distintos tipos ser expresada en OWL aunque no se pretende que
sirva para describir completamente el comportamiento deseado y el
procesado de las respuestas (que necesitara un leguaje de descripcin de
procesos como OWL-S). La razn por la que no se profundiza en el
comportamiento deseado y el procesado de las respuestas se debe a que
194
nuestro inters para lo ontologa no es la ejecucin del curso, sino facilitar

su bsqueda e indexacin en la web semntica.
La parte de consecucin de objetivos se basa en que una actividad puede

servir para evaluar si se han adquirido ciertos objetivos de aprendizaje,
como define SCORM [ADL04c] [ADL04b]. La actividad en s es suficiente
para evaluar ese objetivo totalmente, y puede que haya otras actividades que
tambin evalen la consecucin de ese objetivo de aprendizaje. Un objetivo
se consigue de forma total, es decir, no hay distintos grados de consecucin
de los objetivos de aprendizaje.
Aunque el modelo de referencia SCORM permite asignar elementos

LearnigObjective a elementos Asset (de forma que se cumple cuando un
alumno ha visualizado dicho elemento Asset), en esta Tesis consideraremos
que no se ha obtenido un objetivo de aprendizaje hasta que no se ha
evaluado de alguna forma. La razn por la que se realiza esta distincin se
justifica porque, por elemplo, el hecho de haber descargado un fichero no
significa ni tan siquiera que se haya ledo, por lo que no se considera
adecuado poder obtener un objetivo de aprendizaje nicamente por
descargarse un recurso. El modelo SCORM realiza esta concesin porque
utiliza el concepto de objetivo de aprendizaje para describir la
navegabilidad, mezclando ambos propsitos.
Por tanto, se considerar el objetivo de aprendizaje, representado por la

clase LearningObjective, como un objetivo de aprendizaje indivisible y que
se puede constatar que se ha obtenido por medio del elemento de evaluacin
al que pertenece. Adems, puede definir la temtica sobre la que se
desarrolla la instancia de la clase LearningObjective as como la
clasificacin de tipo de objeto LearningObjective obtenido. Esta definicin
de temtica y clase de objetivo de aprendizaje se especifica siguiendo el
estndar IEEE-LOM-1484.12.1, es decir, con los atributos catalog y entry.
El atributo catalog indica sobre qu catlogo se clasifica y el atributo entry
el valor para identificarlo dentro de la clasificacin. Ambos atributos son
propiedades que relacionan nuestro objeto LearningObjective con una
cadena de texto.
En la especificacin realizada en este captulo no se diferenciar entre

objetivos locales y globales, como s hace SCORM S&N [ADL04c], pero s
entre el concepto de LearningObjective y el concepto de Competence. La
clase Competence representa un nivel ms complejo de resultado adquirido
y se compone de un conjunto de instancias de LearningObjective, aunque
195
puede necesitar ms pruebas a parte de la obtencin de los objetivos de

aprendizaje para considerar que se ha adquirido la competencia. Se define
para poder marcar los contenidos estticos como facilitadores para obtener
una cierta competencia. En este caso los contenidos estticos pueden otorgar
la competencia por completo o necesitar otros elementos para evidenciar la
consecucin de la misma. Las instancias de la clase Competence contendr
las mismas propiedades de datos que la especificacin IMS Reusable
Definition of Competency or Educational Objective Specification (y su
normalizacin en IEEE 1484.20.1), es decir, ttulo, definicin y metadatos,
pero no desarrollar la propiedad definicin por medio de frases (elementos
statements de IEEE 1484.20.1), sino se definir por medio de unas nuevas
propiedades catalog y entry.
Permitiremos que un objeto LearningObjective pueda ser compartido por

varios objetos Competence, de forma que podremos relacionar distintos
objetos Competence por medio de las instancias de la clase
LearningObjective que contienen. Otra forma de relacionar elementos
Competence se realiza por medio de la propiedad catalog, de forma que dos
objetos Competence que pertenecen al mismo catlogo de competencias
estn de algn modo relacionados. No se aborda una relacin directa entre
competencias para simplificar el modelo y evitar relaciones complejas entre
las mismas. La razn por la que no se relacionan las instancias de la clase
Competence entre s de forma directa se debe a que no se puede asegurar
que las competencias tengan algn tipo de estructura detallada, como una
jerarqua en forma de rbol.
Por ejemplo, en la Fig. 6.3 podemos apreciar dos competencias que

comparten el mismo objeto educativo.
196
C1 y C2 se relacionan por los

LO que comparten
Competence Competence
C1 C2
LearningObjective
LO2
LearningObjective
LO1
LearningObjective
LO3
Fig. 6.3. Relacin entre objetos Competence
De la figura 6.3 podemos inferir tambin que si ambas competencias

contienen slo los objetos LearningObjective de la figura, la instancia de
Compentence C1 contiene a la instancia C2.
6.2.3 Ontologa para las interacciones entre usuarios

Esta ontologa es la menos desarrollada y contemplada por los modelos de
referencia, normas y recomendaciones sobre la formacin on-line. Algunos
modelos la contemplan como simple medio a la hora de la imparticin, pero
en ningn caso se trata la posibilidad de potenciar la interoperabilidad de
estas interacciones. En los Sistemas de Gestin de la Formacin (LMSs)
actuales se contemplan estas interacciones como un servicio aadido a la
experiencia educativa. Dicho servicio y la informacin que ha recibido
normalmente desaparece cuando ya se ha impartido dicha experiencia. Sin
embargo, se propone desde esta Tesis la recoleccin y tratamiento de estas
interacciones para poder realizar bsquedas semnticas dentro de las
mismas, aunque ya haya terminado la accin formativa para la que se
crearon. Por tanto podemos considerar que la ontologa especificada en esta
Tesis es pionera en el campo de las interacciones entre usuarios en un
proceso de teleformacin.
El modelo de referencia SCORM [ADL04b] contempla de forma muy

limitada y unidireccional la posible comunicacin en el sentido aprendiz-
197
instructor por medio de los elementos cmi.comments_from_learner,

permitiendo que los elementos SCO almacenen (aunque se profundiza ms
en este tema dentro de la especificacin del modelo de referencia) de alguna
forma un conjunto n de comentarios (al menos se debe poder almacenar
n=250 por SCO), basados en un texto (almacenado en el elemento
cmi.comments_from_learner.n.comment, que ha de soportar al menos
strings de 4000 caracteres), una fecha de creacin
(cmi.comments_from_learner.n.timestamp) y un indicador de a qu parte del
elemento SCO se refiere el comentario (elemento
cmi.comments_from_learner.n.location, con una estructura que no est
definida y depende de cada implementacin del SCO). Se define de forma
similar los comentarios del instructor a los alumnos (comunicacin uno a
muchos) por medio del elemento cmi.comments_from_lms (en este caso
permitiendo un mximo de n=100). En la figura 6.4 podemos ver los dos
tipos de comentarios y los sentidos de la comunicacin.
Comments_from_learner
ALUMNO 1 cv
er
l e arn
o m_ LMS
c
_fr
e nts
mm
Co
ALUMNO 2
Comments_from_lms
Fig. 6.4. Esquema de comments_from_learner y comments_from_lms
En la figura 6.4 se describen los nombres de los elementos que participan en

este sistema. Adems podemos apreciar los distintos sentidos de la
comunicaciones, y que no existe ningn tipo de relacin entre los distintos
comentarios, ms all de pertenecer al mismo elementos SCO.
198
IEEE.1484.11.1 introduce los mismos elementos para las interacciones entre

usuarios, ya que, como el modelo de referencia SCORM, IEEE.1484.11.1 se
basa en AICC Computed Managed Instruction [AICC04]. Incluso mantiene
los mismos valores para los tamaos mnimos y los campos de comentario,
fecha y localizacin. La nica diferencia radica en que en este caso no se
utiliza el prefijo cmi., aunque s que se indica en la descripcin que pretende
definir sin ambigedades la comunicacin definida por AICC CMI.
En ninguno de los casos se relacionan los distintos comentarios entre s (lo

que dara lugar a conversaciones) ni se permite los comentarios entre los
propios aprendices. La utilidad de esta comunicacin es simplemente
generar un feedback desestructurado sobre posibles errores tipogrficos
encontrados y no permite profundizar ms, por medio de una conversacin
sobre las posibles mejoras o temas interesantes no cubierto completamente
por los contenidos estticos del curso.
Podemos ver un esquema comn de las propuestas de IEEE.1484.11.1 y

SCORM en la Fig. 6.5.
comment
COMENTARIO 1
datestamp
COMMENTS_FROM_
LEARNER
location
COMENTARIO n
(n<=250)
Fig. 6.5. Esquema comn de los comentarios en IEEE y en SCORM
En la figura 6.5 podemos ver la conceptualizacin de las dos

especificaciones, de IEEE y de SCORM, de modo que se abstraen los
conceptos comunes, que nos servir para la implementacin de nuestra
ontologa.
199
Nuestra especificacin pretende basarse en estos modelos pero ir ms all de

simples comentarios. Para hacer esto definiremos la interaccin
constructivista (representada por la clase ConstructivistInteraction) como la
abstraccin de las posibles interacciones que puede hacer un participante de
la experiencia educativa con otros participantes (sean alumnos, instructories,
tutores u otras figuras). El concepto de interaccin en este apartado, es
completamente distinto a la mayora de sistemas de aprendizaje, donde se
asimila interaccin a una accin del alumno con el sistema a modo de
contestacin de un test (como se hace [AICC04]).
En nuestro sistema aseveramos que las interacciones se pueden hacer por

medio de comentarios (con una estructura similar a la de IEEE-1484.11.1) o
por medio documentos compartidos, ya que este mtodo es otro mtodo que
permite la interaccin entre los distintos usuarios.
Adems conceptualizaremos los recursos constructivistas (que pertenecern

a la clase ConstructivistWidget) refirindonos a los elementos que nos
sirven en la formacin on-line a compartir experiencias con otros
participantes, como pueden ser Foros, Listas de Correo (entendidas como
Foros en los que responder a un correo es responder a ese comentario y
enviar un correo nuevo es como generar un nuevo Thread del Foro), una
actividad de generacin y modificacin de un recurso en grupo (como puede
ser por medio de la herramienta Wiki [WWW51]). Tambin se incluyen los
sistemas de preguntas frecuentes, que se generan a partir de las interacciones
de los usuarios que plantean los mismos tipos de dudas.
Esta especificacin permitir cubrir la mayora de las posibilidades

constructivistas, profundizando en la de tipo foro y expresar cmo se
podran aadir otras, de modo que la ontologa sea ampliable con nuevas
tcnicas.
En la figura 6.6 podemos ver un resumen de esta parte de la ontologa.
200
Fig. 6.6. Generalizacin de la ontologa de interaccin entre usuarios
Como podemos ver en la figura 6.6, definimos las interacciones

constructivistas y los distintos recursos constructivistas, realizando una
taxonoma de los mismos.
Para definir los foros empezaremos definiendo con un poco ms de detalle

los comentarios (instancias de la clase Comment), definiendo preguntas
(instancias de Question), respuestas a esas preguntas (representadas por la
clase Answer) y comentarios anidados en forma de rbol (clase
TreeComment) que nos servirn para los foros. Tambin describiremos
caractersticas de los Threads (abstraidos en la clase ForumThread) y de los
foros (elementos de la clase Forum).
Tambin definiremos los roles de los autores. La razn por la que no se

identifica al autor con un autor individual, es para proteger el anonimato de
los autores de los foros, ya que esa informacin pretendemos que sobrepase
el contexto de la imparticin del curso y nos sirva para bsquedas y para
aadirlo a otras experiencias educativas. Por esta razn se definen los
distintos roles de la experiencia educativa (profesor, alumno, tutor, etc) que
permitirn marcar de alguna forma el origen de las distintas interacciones.
De esta forma se podrn realizar bsquedas de recursos educativos con un
texto en alguno de los comentarios de un tutor.
201
6.3 Especificacin de una estructura de rbol

En este apartado desarrollaremos la lgica de una estructura de rbol, ya que
nos servir para las partes de nuestra ontologa que se basen en una
estructura de este tipo. OWL no implementa directamente este tipo de
estructuras, por lo que tendremos que definir su lgica inherente.
En nuestro caso haremos una clase TreeStructure que sea subclase de otra
ms genrica llamada Structure. Despus definiremos una clase TreeItem
que abstraer todo objeto de una estructura en rbol. Las clases
TreeStructure y TreeItem se relacionarn por medio de la propiedad
hasFirstTreeItem (propiedad funcional) y su inversa isFirstTreeItemOf
Indicaremos la clase TreeItem como un conjunto de elementos

pertenecientes a la unin de dos clases disjuntas: ClusterItem (elemento que
an tendr otros elementos por debajo de l en su rama del rbol) y la clase
LeafItem (elemento terminal de rbol).
TreeItem (ClusterItem LeafItem ) [Expr. 6.1]

ClusterItem LeafItem
Definimos a su vez una propiedad de objeto (relacin) hasChild (y su

inversa isChildOf) que relaciona un objeto TreeItem con otro objeto
TreeItem, siendo la misma propiedad inversa-funcional (es decir, que un
elemento TreeItem puede tener como mximo un padre). Adems definimos
otra propiedad de objeto para relacionar una instancia de la clase
TreeStructure con su primer elemento por medio de la propiedad funcional
(una estructura de rbol slo puede tener un primer elemento)
hasFirstElement (y su propiedad inversa isFirstElementOf). Como vemos en
la figura 6.7, cualquier instancia de la clase TreeItem puede ser el primer
elemento de una estructura de rbol, pero en todo rbol slo existe una
estructura de rbol que contiene a todas las dems (rbol principal).
Adems, por cada estructura de rbol slo puede un elemento raz TreeItem.
202
Fig. 6.7. rboles y subrboles
En la figura 6.7 podemos observar que existe slo un rbol principal. Por
otro lado, una estructura de rbol puede tener tantos rboles secundarios
como se desee.
Definiremos una propiedad de datos isLeafItem que nos relacionar los

objetos TreeItems con un booleano (de valores true/false) por razones que
veremos a continuacin.
Adems incluiremos las propiedades transitivas hasDescendent y

isDescendetOf, que nos sern de utilidad para los foros y para la ubicacin
de un elemento de la clase TreeItem dentro de una instancia de la clase
TreeStructure.
Definiremos tambin la clase ClusterItem como el conjunto de elementos

TreeItem que tiene por definicin al menos una relacin del tipo hasChild
con un elemento de tipo TreeItem . Es decir, una instancia ClusterItem se
caracterizar por tener al menos alguna propiedad hasChild que lo relaciona
con un elemento de la clase TreeItem.
ClusterItem (TreeItem hasChild .TreeItem ) [Expr. 6.2]
203
A su vez se define un elemento de la clase LeafItem como un objeto

TreeItem que no es un elemento ClusterItem y tiene adems una propiedad
de datos isLeafItem con el valor true.
LeafItem (TreeItem (isLeafItem true )) [Expr. 6.3]
La razn por la que se incluye la propiedad de datos isLeafItem es para

poder marcar un elemento TreeItem directamente como terminal. Al trabajar
con la suposicin de OWA (Open World Assumption), podramos decidir
que un objeto TreeItem es un ClusterItem porque encontramos una relacin
del tipo hasChild con otro objeto TreeItem, pero no podramos decidir si un
TreeItem pertenece a la clase LeafItem por el simple hecho de no haber
encontrado an ninguna relacin hasChild con otra instancia de TreeItem.
De esta forma cuando encontremos que esa propiedad es true sabremos que
es LeafItem, y si la encontramos con el valor false o encontramos algn hijo,
es una instancia de la clase ClusterItem.
Definimos tambin las instancias de la clase RootItem como objetos que

sean TreeITem (ClusterItem o LeafItem) y que no tiene ningn padre:
RootItem (TreeItem (isChildOf .TreeItem )) [Expr. 6.4]
La expresin 6.5 nos servir para definir a su vez una clase

TopTreeStructure (estructura de rbol que no est incluida en otros rboles)
diciendo que son las que su primer elemento es un elemento RootItem:
TopTreeStructure [Expr. 6.5]

(TreeStructure (hasFirstTreeItem.RootItem,))
La razn por la que aparece el concepto de TopTreeStructure es para
permitir que la rama de un rbol sea a su vez un rbol, pero que se pueda
distinguir entre el rbol principal y los subrboles (ver Fig. 6.7.).
Otra de las razones por las que se introduce el elemento RootItem es para
intentar evitar los bucles de referencias. Puesto que un objeto TreeItem
puede tener como mucho un padre, si ya tiene padre no puede tener otro
distinto, y si existe en el rbol un elemento RootItem (que no tiene ningn
padre), ser imposible que exista una referencia circular (ver Fig. 6.8).
204
Fig. 6.8. Existencia de referencias circulares
En la figura 6.8 podemos ver el caso en que no se definieran elementos que

no puedan ser descendientes de otros. Si la instancia de la clase TreeItem C
tiene a B como padre y la B tiene a A como padre, en el caso que la
instancia de la clase TreeItem A tuviera como padre a la instancia C, se
producira un bucle.
En la Fig 6.9 podemos ver la jerarqua de la estructura de rbol, y en la

figura 6.10 las distintas propiedades que relacionan los objetos.
Fig. 6.9. Jerarqua de la estructura de rbol
En la figura 6.9 destaca la definicin de las subclases no excluyentes de

TreeItem: ClusterItem, RootITem y LeafItem. En paralelo podemos ver los
conceptos de estructura definidos: Structure, TreeStructure y
TopTreeStructure.
A partir de la propiedad isChildOf podramos haber pensado en definir la

propiedad hasSibling como propiedad simtrica que indica que si dos
205
instancias de la clase TreeItems distintas tienen el mismo padre (relacin por

medio de la propiedad isChildOf con el mismo padre) entonces se
relacionan por medio de la propiedad hasSibling:
XYZ TreeITem, [Expr. 6.6]

owl : differentFrom( X , Y )
isChildOf ( X , Z )
isChildOf (Y , Z ) hasSibling ( X , Y )
En la expresin 6.6 tenemos la regla derivada de la definicin de la

propiedad hasSibling definida en el prrafo anterior, y que se corresponden
con la definicin comn en la mayora de estructuras en rbol.
Sin embargo OWL DL no permite la asercin de reglas, por lo que no

podramos a priori realizar este tipo de afirmacin. Este tipo de debilidad
viene indicado por autores como [CRE05], y por eso existe una propuesta de
combinacin entre OWL DL y RuleML: SWRL [SWRL04]. En el caso de
utilizar SWRL la regla quedara como se indica en el ejemplo 6.1:
<swrl:Variable rdf:ID="x"/>
<swrl:Variable rdf:ID="z"/>
<swrl:Variable rdf:ID="y"/>
<swrl:Imp rdf:ID="ReglaSibling">
<swrl:body>
<swrl:AtomList>
<rdf:first>
<swrl:IndividualPropertyAtom>
<swrl:argument1 rdf:resource="#x"/>
<swrl:propertyPredicate
rdf:resource="#isChildOf"/>
<swrl:argument2 rdf:resource="#z"/>
</swrl:IndividualPropertyAtom>
</rdf:first>
<rdf:rest>
<swrl:AtomList>
<rdf:rest>
<swrl:AtomList>
<rdf:first>
<swrl:DifferentIndividualsAtom>
<swrl:argument2 rdf:resource="#y"/>
</swrl:DifferentIndividualsAtom>
</rdf:first>
<rdf:rest
rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-
206
ns#nil"/>
</swrl:AtomList>
</rdf:rest>
<rdf:first>
rdf:resource="#isChildOf"/>
<swrl:argument2 rdf:resource="#z"/>
</rdf:first>
</swrl:AtomList>
</rdf:rest>
</swrl:AtomList>
</swrl:body>
<swrl:head>
<swrl:AtomList>
<rdf:first>
rdf:resource="#hasSibling"/>
</rdf:first>
<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-
rdf-syntax-ns#nil"/>
</swrl:AtomList>
</swrl:head>
</swrl:Imp>
Ejemplo 6.1. Ejemplo de regla en SWRL
Como podemos destacar de las partes resaltadas del texto del ejemplo 6.1,
SWRL s que permite realizar aserciones de reglas (conocidas como tambin
como implicaciones). En este caso separa entre un cuerpo, indicado por la
marca <body> y una cabecera, indicado por la marca <head>. El cuerpo
contiene los condicionantes de la regla y la cabecera la consecuencia de
dicha regla.
Sin embargo en esta Tesis no se contemplarn las reglas, ya que estn fuera
del alcance de OWL DL, lenguaje en el que expresaremos nuestra ontologa.
De todas formas SWRL permite utilizar ontologas OWL, por lo que se
podra en un futuro ampliar esta ontologa con reglas y producir una
ontologa en lenguaje SWRL. Para los objetivos de esta Tesis no se
considera necesario.
207
Fig. 6.10. Propiedades de relacin de los objetos
En la figura 6.10 podemos ver las propiedades que relacionan entre s a las
instancia de TreeItem y de la clase TreeStructure. Se basan en una relacin
de padre/hijo entre objetos TreeItem y una propiedad isLeafItem que permite
marcar a los elementos terminales. Por otro lado tenemos la relacin de una
estructura de tipo rbol con su primer elemento del rbol, por medio de la
propiedad hasFirstTreeItem y isFirstTreeITemOf. Adems vemos en la
figura la cardinalidad de las distintas relaciones, indicando con * cuando
dicha cardinalidad no est limitada. Tambin indicamos dentro de las
distintas clases las propiedades de tipos de datos que relacionan a cada
instancia con un dato numrico, booleano, de texto o similares.
6.4 Especificacin de la ontologa para los contenidos

estticos
En este apartado realizaremos la especificacin formal de los contenidos que
han sido creados previamente a la fase de imparticin de una experiencia
educativa y que no generan informacin sobre la consecucin de objetivos
educativos por parte del alumno.
La especificacin se basar en la concrecin por medio de expresiones

lgicas y posterior traslacin a OWL de los conceptos de Learning Content
Package, Organization y Learning Activity, y utilizar la ontologa auxiliar
de estructura de rbol planteada en el apartado anterior. Puesto que esta
especificacin se basa en el modelo de referencia SCORM, incluiremos el
sufijo SCORM a nuestras denominaciones.
Las clases definidas son las siguientes:
208
SCORMContentPackage. Es la representacin del concepto de

Learning Content Package y se relaciona al menos con un elemento
SCORMOrganization por medio de la propiedad de objeto
hasOrganization, funcin inversa-funcional (una instancia de
SCORMOrganization slo puede estar en un nico
SCORMContentPackage).
SCORMContentPackage hasOrganization.SCORMOrganization [Expr. 6.7]
En la expresin 6.7 podemos ver se indica que los objetos de la clase

SCORMContentPackage estn incluidos dentro del conjunto de los
objetos que tienen al menos una relacin por medio de la propiedad
hasOrganization con una instancia de la clase SCORMOrganization.
SCORMOrganization. Es la representacin del concepto

Organization y est relacionado con mltiples instancias de la clase
SCORMLearningActivity por medio de la propiedad hasChild. Esto
significa que todo elemento SCORMOrganization es a su vez el
primer elemento (elemento raz) de una estructura de tipo rbol.
SCORMOrganization RootItem [Expr. 6.8]

hasChild .SCORMLearningActivity
Como vemos en la expresin 6.8, la clase SCORMOrganization est

incluida dentro de la clase RootItem y adems si tiene alguna
relacin por medio de la propiedad hasChild es con una instancia de
SCORMLearningActivity. Esto nos permitir definir a partir de aqu
una estructura de tipo rbol con instancias de la clase
SCORMLearningActivity que vemos a continuacin.
SCORMLearningActivity. Es la representacin del concepto de

Learning Activity y se caracteriza por ser un elemento no raz de la
estructura del rbol, como se describe en la expresin 6.9.
SCORMLearningActivity TreeItem RootItem [Expr. 6.9]

hasChild .SCORMLearningActivity
En la expresin 6.9 se aprecia que las instancias de la clase

SCORMLearningActivity son tambin instancias de la clase TreeItem
que no son del tipo RootItem y adems que slo se relacionan por
209
medio de la propiedad hasChild con instancias de su misma clase

SCORMLearningActivity.
SCORMLeafLearningActivity son Learning Activities que se

caracterizan por ser elementos terminales de la estructura de rbol y
por estar relacionados con una SCORMResource (relacin
funcional). Tiene como subclases disjuntas SCORMAsset y
SCORMSCO.
SCORMLeafLearningActivity [Expr. 6.10]

SCORMLearningActivity
LeafItem
hasSCORM Re source.SCORM Re source
SCORMLeafLearningActivity
SCORMAsset SCORMSCO
SCORMAsset SCORMSCO
Como indica la expresin 6.10, una instancia de la clase

SCORMLeafLearningActivity se define por ser una instancia de la
clase SCORMLearningActivity que es adems una instancia de la
clase LeafItem y que tiene al menos una relacin con una instancia
de la clase SCORMResource por medio de la propiedad
hasSCORMResource. Adems cualquier instancia de esta clase es o
una instancia de la clase SCORMAsset o una instancia de la clase
SCORMSCO.
SCORMResource. Es una descripcin simple de un recurso, que

identifica por medio de su URI. Contiene una propiedad funcional de
datos hasURI que relaciona el objeto con un tipo de datos
xsd:anyURI.
SCORM Re source hasURI .xsd : anyURI [Expr. 6.11]
En la figura 6.11 podemos contemplar la jerarqua resultante de la ontologa

de contenidos estticos. En la figura 6.12 podremos observar un resumen de
sus propiedades principales.
210
Fig. 6.11. Jerarqua de la ontologa para los contenidos estticos
En la figura 6.11, extrada de la herramienta de generacin de ontologas de

Protg-OWL[WWW78] (en particular su ampliacin para visualizacin de
ontologas OWLViz[WWW79]) observamos unas clases nuevas como la
clase Structure, que nicamente indica que sus subclases son estructuras de
algn tipo, y de esta forma permitir ampliaciones de la ontologas con otras
estructuras que se definan en un futuro. En la figura 6.11 se representan,
adems, las clases que especificamos para la estructura de rbol, ya que se
utilizan en esta ontologa. En amarillo tenemos las clases primitivas, es
decir, las clases en las que slo indicamos propiedades que son condiciones
necesarias para pertenecer a la misma, y en naranja las clases definidas, en
las que definimos propiedades que son necesarias y suficientes para que un
objeto se pueda considerar perteneciente a esa clase.
211
Fig. 6.12. Propiedades de relacin para los contenidos estticos
Como apreciamos en la figura 6.12, podemos decir a modo de resumen que

cada objeto SCORMContentPackage est relacionada al menos con una
instancia de SCORMOrganization, que a su vez el nodo raz de un rbol de
objetos SCORMLearningActivity. La clase SCORMLearningActivity se
divide en dos subclases (indicado en la figura por medio de flechas ms
gruesas), en funcin de si es subclase de LeafItem o no (y por tanto subclase
de ClusterItem). Los objetos terminales del rbol (instancias de LeafItem),
estn relacionados con un SCORMResource, que es que un objeto que
encapsula una URI. Ese objeto SCORMResource puede ser el recurso de
ms de un LeafItem, permitiendo que esta forma que un recurso educativo
sea referenciado por ms de una estructura de rbol.
212
6.5 Implementacin de la ontologa para las

interacciones alumno-sistema
El objetivo de esta ontologa es representar por medio de lenguajes
ontolgicos la lgica existente en las interacciones descritas en el captulo
Primeras interacciones: Evaluaciones. De este modo, la ontologa
especificada en este apartado ser la que nos servir para permitir a los
agentes inteligentes la realizacin de bsquedas dentro de las distintas
evaluaciones de una experiencia educativa.
Para llevar a cabo la implementacin de la ontologa se distingue entre la

parte de descripcin de las actividades de evaluacin a realizar y la
descripcin de los resultados a obtener, siguiendo la filosofa conceptual del
modelo de referencia SCORM, donde se separa entre las actividades SCOs
que pueden comunicarse con el LMS e indicar los distintos
LearningObjective que se han alcanzado. No mezclaremos la navegabilidad
con los objetivos de aprendizaje, ya que no se considera importante para
permitir la interoperabilidad. En la figura figura 6.2 se pudo observar los
distintos conceptos descritos en esta ontologa. A continuacin veremos por
separado la parte dedicada a la descripcin de las actividades de evaluacin,
basndonos en IMSQTI y despus la descripcin en lgica descriptiva de los
distintos conceptos utilizados para la descripcin de los objetivos a
conseguir por el alumno, siguiendo la filosofa de TeML, donde cada
evaluacin permita evidenciar el dominio de un concepto determinado.
6.5.1 Descripcin de las actividades de evaluacin

Las actividades para la interaccin alumno-sistema representan en esta
ontologa las herramientas conductistas del aprendizaje, y comprender los
distintos tests de evaluacin que se pueden realizar en un proceso de
aprendizaje. Dichas actividades se representarn en nuestra definicin de
ontologa por medio de instancias de la clase AssessmentActivity. La clase
AssementActivity se define como una especializacin de la clase ya definida
SCORMSCO, que se defini en la ontologa de contenidos estticos. Las
instancias de la clase AssessmentActivity contienen al menos una propiedad
de los relaciona con un elemento evaluable, que representaremos por medio
de instancias de la clase AssessmentItem. Las instancias de la clase
AssementActivity se caracterizan tambin por tener una propiedad
obligatoria completionThreshold, con un valor comprendido entre [0,1] que
define el valor final que han de sumar todas las respuestas del alumno como
213
mnimo para que se considere la actividad como superada satisfactoriamente

(y por tanto, sus objetivos de aprendizaje obtenidos):
AssesmentActivity [Expr. 6.12]

( SCORMSCO)
(hasAssessmentItem 1)
(completionThreshold = 1)
En la expresin 6.12 se indica adems que las instancias de la clases

AssessmentActivity deben contener al menos una elemento unitario de
evaluacin, representado por medio de la propiedad hasAssessmentItem. Los
elementos evaluables AssessmentItem tienen una estructura parecida a la de
IMS QTI, es decir, tienen un cuerpo del elemento (equivalente al enunciado
de una pregunta), un proceso de evaluacin de la respuesta del alumno y un
posible Feedback en caso necesario. Podemos ver las relaciones en la figura
6.13.
hasLearningObjective
AssessmentActivity (*,*)
completionThreshold (xsd :float )
LearningObjective
hasAssessmentItem
(1,*)
AssessmentItem
hasBodyURI (xsd:AnyURI )
hasFeedback
(1,1)
hasCorrectResponse
(1,*)
Feedback
hasFeedbackURI (xsd:AnyURI )
Response
hasOutcomeValue (xsd :float )
Fig. 6.13. Relaciones de los elementos evaluables
En la figura 6.13 podemos apreciar que una instancia de la clase

AssementActivity tiene una propiedad de tipo de datos completionThreshold,
que puede tener un valor de coma flotante, Adems, se puede relacionar por
medio de una relacin muchos a muchos con distintas instancias de la clase
LearningObjective, lo que indica que una instancia de AssessmentActivity
214
puede hacernos conseguir ms de un objeto LearningObjective, y que a su

vez un mismo LearningObjective se puede obtener desde distintos objetos
LearningActivity. Las instancias de AssessmentItem se relacionan con
distintos objetos Response por medio de la propiedad hasCorrectResponse.
Esta relacin indica que esa posible respuesta representada por medio de
una instancia Response, si la contesta el alumno, se ha de puntuar con el
valor de su propiedad de datos hasOutcomeValue. Las distintas respuestas
relacionadas con un objeto de la clase AssessmentITem por medio de
hasCorrectResponse no tienen por qu indicar que son correctas. Es el valor
de la propiedad hasOutcomeValue lo que indicar la exactitud de la misma.
De esta forma si, por ejemplo, un elemento de la clase Response tiene un
valor en hasOutcomeValue menor que cero, indica que si el alumno elige
esa contestacin, se le restar puntuacin a la hora de evaluar si se ha
conseguido aprobar el objeto LearningAssessment y por tanto haber
obtenido los objetivos de aprendizaje correspondientes. Si no hay una
relacin por medio de hasCorrectResponse con el valor de la respuesta del
alumno, se supone que se asigna un valor 0 a esa respuesta.
El proceso de evaluacin de la respuesta no se define para cada caso como

en IMS QTI, sino que se considera ms apropiado definir tipos de elementos
evaluables. Esta parte se basar en parte en el modelo de datos de IEEE para
las comunicaciones entre el alumno y el sistema, IEEE 1484.11.1[IEEE05].
Se puede considerar que los distintos tipos de elementos evaluables abstraen
un conjunto de posibles processingTemplates de IMS QTI, uno por cada
tipo de elemento evaluable. Por ejemplo, podemos considerar que todas las
preguntas de test con slo una respuesta correcta se procesan de igual forma,
por lo que pueden compartir el mismo processingTemplate en IMS QTI. Por
tanto, cada tipo de elemento evaluable puede tener un tipo definido de
respuesta. Esta decisin sacrifica una mayor flexibilidad que nos ofrece IMS
QTI, ya que evala la respuesta de forma abstracta por medio de reglas, a
cambio de una mayor claridad y sencillez en la metainformacin. Otra razn
por la que no se realiza una descripcin del procesamiento es de nuevo la
necesidad de ampliar OWL a OWL-S (u otro lenguaje superior de
descripcin de procesos), no siendo de gran inters esta descripcin para las
bsquedas en repositorios.
Como se indica en la figura 6.13, puede haber varias relaciones

hasCorrectResponse, donde cada respuesta de las posibles definidas tenga
una puntuacin distinta, incluso negativa (respuestas que restan). Esto
difiere de IEEE 1484.11.1, donde no se especifica la forma de convertir una
respuesta de un alumno en un resultado (numrico o no). Adems, este valor
215
de la propiedad hasOutcomeValue nos permite prescindir de otra parte de

ponderacin entre elementos evaluables, ya que se puede realizar por medio
de este valor.
Re sponse [Expr. 6.13]

hasOutcomeValue.xsd : float hasOutcomeValue = 1
Como se distingue en la expresin 6.13, las respuestas han de tener

exactamente una propiedad hasOutcomeValue que lo relaciona con un tipo
de datos de coma flotante. La propiedad hasOutcomeValue ha de contener
un valor obligatoriamente para todas las respuestas, incluso las que no se
corrigen automticamente, ya que incluye el concepto de ponderacin de la
pregunta.
Para ser capaces de indicar explcitamente el tipo de pregunta y procesado

de la respuesta, se definen subclases de AssessmentItem por cada tipo de
interaccin de IEEE 1484.11.1, y se definen a su vez el formato de sus
posibles respuestas. En la figura 6.14. podemos ver las diferentes subclases
de la clase AssessmentItem y en la figura 6.15 podemos ver los tipos de
respuesta relacionados.
216
Fig. 6.14. relaciones de herencia entre las clases
La definicin de los distintos tipos de respuestas se hace indicando el tipo de

valor que puede tener la respuesta, y permitiendo una o mltiples valores
por respuesta en funcin del tipo de pregunta que sea. Por ejemplo:
TrueFalseAI es una subclase de la clase AssessmetItem que slo

permite respuestas correctas del tipo TrueFalseResponse. Adems,
indicamos que los distintos subtipos de la clase AssessmentItem son
disjuntos entre s, es decir, que una instancia de la clase TrueFalseAI
no puede ser a su vez instancia de ningn otro tipo de pregunta..
[Expr. 6.14]
TrueFalseAI ( AssessmentItem ) (hasCorrect Re sponse.TrueFalse Re sponse )
TrueFalseAI FillInAI MatchingAI K MultipleChoiceAI
Como vemos en la expresin 6.14, si un elemento pertenece a la

clase TrueFalseAI, tendr todas sus respuestas como instancias del
tipo TrueFalseResponse y no podr pertenecer a otra subclase de la
217
clase AssessmentItem (no puede ser un elemento de FillInAI, por

ejemplo).
La clase TrueFalseResponse es una especializacin de la clase

Response que tiene una propiedad funcional TFResponseValue que
lo relaciona con un booleano, y adems slo se da esa propiedad una
vez por respuesta, como indica la expresin 6.15.
[Expr. 6.15]
TrueFalse Re sponse Re sponse (TF Re sponseValue.xsd : boolean )
TrueFalse Re sponse TF Re sponseValue = 1
FillInAI, ser tambin una subclase de AssessmentItem, slo que en

este caso se permite rellenar hasta 10 huecos de texto por respuesta
(como indica el modelo de datos de IEEE 1484.11.1 para las
preguntas de rellenar huecos), e indica si es importante el orden de
los strings y si diferencia entre maysculas y minsculas:
[Expr. 6.16]
FillInAI ( AssessmentItem ) (hasCorrect Re sponse.FillIn Re sponse )
FillInAI MatchingAI LongFillInAI K TrueFalseAI
FillIn Re sponse Re sponse FI Re sponseValue.xsd : String

FillIn Re sponse (FI Re sponseValue.xsd : String 10 )
FillIn Re sponse caseMatters.xsd : boolean caseMatters = 1
FillIn Re sponse orderMatters.xsd : boolean orderMatters = 1
En la expresin 6.16 vemos reflejado en lgica descriptiva tanto las

restricciones de la clase FillInAI como las aserciones respecto a la
clase de respuesta que define FillInResponse. La clase FillInAI se
define de forma muy similar a la clase TrueFalseAI, y para la clase
de respuesta FillInResponse podemos destacar su propiedad
FIResponseValue que lo relaciona con una cadena de caracteres,
pudiendo tener hasta 10 relaciones con cadenas de caracteres por
medio de la propiedad FIResponseValue. Tambin vemos las
propiedades nicas de valores boolean caseMatters y orderMatters.
218
SequencingAI. Para respuestas que necesitan tipos de datos

complejos (como por ejemplo las instancias de la clase
SequencingAI que necesita para cada elemento de la respuesta el
orden y el identificador del elemento de secuencia) se definen clases
auxiliares aparte de la clase de respuesta. En el caso de
SequencingAI definimos, adems de la subclase de respuesta
SequenceResponse, una nueva clase denominada SequenceItem.
[Expr. 6.17]
SequenceAI ( AssessmentItem ) (hasCorrect Re sponse.Sequence Re sponse )
SequenceAI FillInAI MatchingAI K TrueFalseAI
Sequence Re sponse Re sponse S Re sponseVaule.SequenceItem

Sequence Re sponse S Re sponseValue 36
SequenceItem SOrder.xsd : int eger SOrder = 1

SequenceItem SValue.xsd : ID SValue = 1
En la expresin 6.17 vemos que, adems de definir la subclase de

elemento de evaluacin SequenceAI, el tipo de respuesta
SequenceResponse, que permite tener hasta 36 instancias de la clase
SequenceItem (lmite que coincide con la especificacin de IEEE
1484.11.1). relacionadas por medio de la propiedad ResponseValue.
Tambin se indica que los elementos de la clase SequenceItem
tendrn las propiedades nicas SOrder y SValue que los relacionan
con un entero y un identificador respectivamente.
El resto de tipos de respuesta definidos en IEEE 1484.11.1 se definen de la

misma forma que los tres ejemplos anteriores. En la figura 6.15 podemos
ver los tipos de Respuesta posible as como las clases que abstraen los
valores de respuesta compuestos. Estas clases auxiliares que aadimos son:
NumericInterval, que abstrae el concepto de un intervalo entre un

valor mnimo y mximo. Las instancias de la clase NumericInterval
tienen dos propiedades de datos xsd:float funcionales y obligatorias
maxInterval y minInterval, que nos definen el intervalo inclusivo
(como define IEEE.1484.11.1) de posibles valores, [minInterval,
maxInterval]. No se contempla la posibilidad de lmites superior o
inferior infinito, que en IEEE.1484.11.1 se hace por medio de la no
219
definicin del parmetro superior o inferior. La razn por la que no

se sigue en este punto IEEE.1484.11.1 estriba en que al trabajar con
una suposicin OWA, el hecho de no tener en nuestra base de
conocimiento uno de los dos extremos del intervalo no significa que
no exista, por lo que nunca podremos concluir que hay una ausencia
de ese extremo del intervalo, sino simplemente que no lo hemos
localizado de momento.
PerformanceStep, clase que nos servir para definir un conjunto de

pasos o acciones de un proceso, teniendo los parmetros de nombre
(definido en la propiedad stepName) como obligatorio y el orden
(propiedad stepOrder). Puede que los pasos no tengan por qu seguir
un orden definido, por lo que habr otra propiedad booleana
orderMatters. Tambin contiene el valor del paso, entendido como
la forma de describir la accin o valor de la accin del proceso.
Dicho valor de paso puede ser un xsd:string (definido en la
propiedad stepString) o un objeto de la clase NumericInterval,
dependiendo de si es una instancia de la subclase
StringPerformanceStep o de la otra subclase
NumericPerformanceStep respectivamente.
MatchItem, siendo esta clase la que nos sirve para valores de

respuesta que relacionan dos opciones entre s, y tiene una fuente
(indicada en la propiedad hasSource) nica y definida por su xsd:ID
y un conjunto de posibles opciones destinto (relacionadas con la
instancia de la clase Matchtem por medio de la propiedad hasTarget)
tambin definido por su xsd:ID.
220
Figura 6.15. Distintos tipos de respuesta y clases que representan valores de

respuesta compuestos
6.5.2 Descripcin de los resultados

Los resultados que se pueden obtener por medio de la realizacin de
actividades de evaluacin se representa por medio de los objetivos de
aprendizaje (abstraidos en la clase LearningObjective), que a su vez se
agregan en competencias (abstraidos en la clase Competency), no siendo a
veces suficiente un conjunto de instancias de LearningObjective para
obtenerla (por ejemplo, se puede necesitar como evidencia al menos tres
aos de experiencia laboral en una determinada materia, aparte de aprobar
algunos exmenes).
A continuacin describiremos el proceso de obtencin de objetivos de

aprendizaje por parte de un alumno por medio de la contestacin de los
tests. A la respuesta de un alumno a una instancia de AssessmentActivity se
le asignar un valor para la propiedad hasOutcomeValue igual al que haya
221
en la instancia de CorrectResponse de la actividad cuyos valores de

respuesta sean iguales a los contestados por el alumno. Para poder
evidenciar que un alumno ha conseguido un objetivo de aprendizaje, ha de
superar satisfactoriamente un elemento AssessmentActivity que conduzca a
evidenciar dicho objetivo de aprendizaje. Esta relacin entre una instancia
de AssessmentActivity y una instancia de LearningObjective se implementa
por medio de la propiedad hasLearningObjective. Como hemos visto antes,
para superar satisfactoriamente un AssessmentActivity el alumno ha de
conseguir una puntuacin suma de sus valores de resultado para cada
elemento AssessmentItem (que se almacenar en la variable
completionStatus cuando se realice una evaluacin a un alumno) que supere
al valor de la propiedad completionThreshold definida en la actividad.
[Expr. 6.18]
completionStatus AssessmentItemi .Student Re sponse.hasOutcomeValue
i
completionStatus AssessmentActivity.completionThreshold
En la expresin 6.18 vemos cmo se calcula en una interaccin si se ha

completado con xito o no una elemento AssessmentActivity. Se sumaran
todos los resultados a las respuestas del alumno a los elementos
AssementItem de la actividad, y si dicho valor es superior al valor
almacenado en la propiedad completionThreshold de la actividad, se
considerar como superada y el alumno habr obtenido todos los objetivos
de aprendizaje relacionados con dicha actividad. Este apartado es un inciso
de cmo debe actuar un LMS en tiempo de ejecucin y por tanto no est
incluido en la ontologa, ya que la lgica descriptiva no permite representar
operaciones matemticas ni reglas de actuacin.
Las instancias de la clase LearningObjective contienen una propiedad de

tipo String (propiedad description) que define una pequea descripcin del
objetivo de aprendizaje. Adems, un elemento de la clase LearningObjective
puede estar relacionado con mltiples instancias de la clase Competency por
medio de la propiedad de objeto contributesToCompetency.
La clase Competency se define de forma similar a IMS RDCEO [IMS02],

incluyendo los campos de ttulo (propiedad hasTitle), su ubicacin en algn
catlogo de competencias (por medio de las propiedades hasCatalog y
hasEntry) y un conjunto de listas (representadas por medio de rdf:List), con
al menos una lista, que define de forma cerrada todos los objetos de la clase
LearningObjective que son necesarios para la competencia. La razn por la
222
que se utiliza una lista cerrada es para poder definir de forma clara
conjuntos completos de instancias de la clase LearningObjective que
consiguen hacen que se considere como probada esa competencia abstrada
en la instancia de la clase Competency. De esta forma se podr asegurar que
se han superado todas los objetivos de aprendizaje necesarios para
evidenciar la adquisicin de la competencia. Habr competencias que
necesiten objetivos de aprendizaje que no se puedan obtener por medio de
exmenes, como puede ser un nmero de aos de experiencia en un sector.
En la Fig. 6.16 podemos las relaciones entre los distintos objetos y sus
propiedades bsicas.
rdf:rest hasLearningObjectives Competence

(*,1) (*,*) hasTitle(xsd:String)
rdf:List hasCatalog(xsd:String)
hasEntry(xsd:String)
LearningObjectives
rdf:first contributesToCompetency
(*,1) (*,*)
AssessmentActivity
hasLearningObjective
(*,*) LearningObjective
Figura 6.16. Relaciones de los objetos LearningObjective con el resto de

objetos
En la figura 6.16 apreciamos que existe una clase que es una especializacin
de la lista cerrada rdf:List, que se denomina LearningObjectives. Esta lista
contiene un conjunto cerrado de elementos de la clase LearningObjective.
Por otro lado, tenemos la clase Competence que puede estar relacionado con
varias listas de objetivos por medio de la propiedad hasLearningObjectives.
Adems, los objetos de la clase LearningObjective se relacionan con los
objetos de la clase Competency por medio de la propiedad
contributesToCompetency. Aunque en un principio podemos considerar que
existe redundancia al relacionar los objetos LearningObjective con los
objetos Competency de forma directa e indirecta por medio de la clase
LearningObjectives, dicha relacin es necesaria ya que en nuestra lgica
descriptiva representada en OWL DL no se pueden realizar aserciones de
reglas, como s permite SWRL.
223
6.6 Implementacin de la ontologa las interacciones

entre usuarios
En este apartado trataremos de la ontologa que representa el aprendizaje
constructivista, es decir, el que se produce por medio de la interaccin
informal y poco estructurada entre los distintos actores del proceso
formativo, ya sea el tutor u otros estudiantes. Estos conceptos son los menos
desarrollados y contemplados por los distintos modelos de referencia,
normas y recomendaciones sobre la formacin on-line, por lo que ser una
de las partes ms innovadoras e inditas de la Tesis, y se basar menos en
conceptos subyacentes en estndares, como se ha realizado en las otras dos
ontologas. Algunos modelos, como SCORM[ADL04b] e
IEEE.1494.11.1[IEEE05], contemplan las interacciones entre actores del
proceso formativo como un simple medio a la hora de la imparticin, pero
en ningn caso se trata la posibilidad de potenciar la interoperabilidad de
estas interacciones, mientras est demostrado que en estas informaciones se
almacena una gran cantidad de formacin especfica, ya que existe una gran
cantidad de bases de conocimiento como[WWW73][WWW74], que se
basan en foros de discusin en los que el usuario puede buscar
conversaciones relacionadas con su temtica de inters. En los Sistemas de
Gestin de la Teleformacin (LMSs) actuales se contemplan estas
interacciones como un servicio aadido a la experiencia educativa. Dicho
servicio y la informacin que ha recibido normalmente existe nicamente
durante el periodo de aprendizaje de una edicin de un curso,
desapareciendo cuando ya se haya impartido la experiencia. Sin embargo, se
propone desde esta Tesis el desarrollo de un grupo de conceptos en la
ontologa que facilite la recoleccin y tratamiento de estas interacciones,
para poder realizar bsquedas semnticas dentro de las mismas, aunque
haya terminado la accin formativa para la que se crearon. Por tanto
podemos considerar la ontologa desarrollada en esta Tesis como pionera en
el campo de las interacciones entre usuarios en un proceso de teleformacin.
La ontologa de relaciones entre usuarios arranca de un concepto primitivo

que denominaremos ConstructivistWidget. Esta clase contendr a todos los
elementos que potencien la comunicacin constructivista entre los usuarios.
Como especializaciones de esta clase encontraremos la clase que agrupa a
todos los foros, denominada Forum, otra clase que abstrae las bateras de
cuestiones y respuestas, tambin conocidas como FAQs, y que se
representar por medio de la clase QuestionAndAnswer. Tambin se
contempla la escritura colaborativa, por medio de los objetos de la clase
GroupWriting, y las tareas en grupo por medio de la clase GroupTask. La
224
interaccin constructivista que especificaremos a partir de este punto es la

ms utilizada en las experiencias educativas por internet: los Foros.
Por tanto, la clase Forum ser una subclase de la clase ConstructivistWidget

con una propiedad de datos para su ttulo (propiedad denominada
forumName) y otra propiedad de objeto denominada hasForumThread para
relacionarlo con mltiples instancias de la clase ForumThread. Esta ltima
propiedad ser inversa funcional, de forma que un objeto ForumThread slo
tenga un nico foro del que dependa. Adems, un objeto de la clase Forum
estar relacionado con la ontologa de contenidos estticos, de forma que
todo foro est relacionado con una instancia de la clase
SCORMLearningActivity por medio de la propiedad relatedTo.
Forum ConstructivistWidget [Expr. 6.19]

Forum hasForumThread .ForumThread
Forum relatedTo.SCORMLearningActivity relatedTo = 1
Como vemos en la expresin 6.19, un objeto de la clase Forum es una

especializacin de la clase ConstructivistWidget y adems se relaciona con
una conjunto de objetos ForumThread por medio de la propiedad
hasForumThread. Tambin podemos apreciar que un objeto de la clase
Forum est relacionado de forma nica con un objeto de la clase
SCORMLearningActivity.
Las instancias de la clase ForumThread estarn relacionadas por medio de

la propiedad hasForumThread y su inversa isThreadOf con un nico objeto
de la clase Forum. Adems, cada elemento de la clase ForumThread ser
una estructura de rbol principal (clase TopTreeStructure). Como ltima
restriccin diremos que tendr como primer elemento de esa estructura un
tipo de comentario TreeComment (que definiremos a continuacin) de
forma obligatoria.
ForumThread isThreadOf .Forum [Expr. 6.20]

ForumThread TopTreeStructure
ForumThread hasFirstElement.TreeComment
Los objetos de la clase ForumThread no tendrn propiedades como ttulo u

otro identificador, ya que sern descritos por su primer elemento , que ser
una instancia de la clase TreeComment. Es decir, un objeto de la clase
ForumThread cuyo primer elemento tenga el ttulo problemas al
225
implementar SingleTones en java se representar con ese ttulo, ya que

consideramos que una conversacin trata sobre su primer comentario.
Describiremos en la ontologa tambin las distintas interacciones bsicas en

un proceso constructivista, agrupadas en la clase ConstructivistInteraction, y
que tendrn en esta ontologa dos subclases iniciales, una primera clase que
representa las interacciones por medio de un comentario, denominada
Comment y otra interaccin que represente la publicacin de algn
documento que se trabaje entre un grupo de usuarios, que denominaremos
Document.
La representacin de los comentarios por medio de la clase Comment tendr

las siguientes propiedades (ver Fig 6.17 ):
Texto (propiedad text), propiedad de datos funcional que tiene el

mismo cometido que la propiedad
comments_from_learner/lms.n.comment de IEEE.1494.11.1. Esta
propiedad almacena la cadena de caracteres con el comentario
escrito por el usuario.
Fecha de creacin (propiedad dateOfCreation), propiedad tambin

funcional y con el mismo objetivo a su vez que la propiedad
comments_from_learner/lms.n.timeStamp de IEEE.1494.11.1. En
este caso ser un valor del tipo xsd:dateTime.
Rol del autor del comentario (propiedad authorRole), propiedad de

objeto que lo relacionar de forma funcional con un tipo de autor
(instancia de la clase Role, que definiremos ms adelante).
Documento adjunto, por medio de la propiedad hasAttachment,

propiedad de objeto que permitir que un comentario tenga ningn o
ms de un documento relacionado ( instancia de la clase Document,
que describiremos ms adelante).
Como podemos ver los comentarios definidos en esta ontologa aaden

informacin relevante, como el tipo de autor y los posibles attachments,
campos no contemplados por otras especificaciones. Sin embargo, no
contiene la localizacin del comentario, ya que sta se encontrar en la
estructura en la que est el comentario (por ejemplo, en el objeto de la clase
Forum si es un foro).
226
Fig. 6.17. Propiedades de Comment
Definiremos a su vez tres tipos de comentarios, que no sern disjuntos, que

sern las preguntas (clase Question), las respuestas (clase Answer)
(relacionados entre ambos por las propiedades isQuestionOf y hasAnswer) y
el tipo que nos interesa para la definicin de los foros que ser el comentario
en estructura de rbol, representado mediante la clase TreeComment.
Question Comment hasAnswer. Answer [Expr. 6.21]

Answer Comment isAnswerOf .Question isAnswerOf = 1
TreeComment Comment TreeItem
En la expresin 6.21 vemos como se especifican las preguntas y las

respuestas, as como la asercin que indica que la clase TreeComment
pertenece a la interseccin entre la clase Comment y la clase TreeItem, por
lo que una instancia de TreeComment tendr las propiedades de un
comentario ms las de un elemento de rbol. Por tanto, los objetos de la
clase TreeComment tendrn las siguientes propiedades heredadas:
Las propiedades heredadas por ser un TopTreeComment: hasChild,

isFirstTreeItemOf, hasDescendent, isLeafItem. Estas propiedades
nos permiten configurar los comentarios en una estructura de rbol,
como cualquier foro.
Las propiedades heredadas por ser un Comment (las descritas

anteriormente). Estas propiedades nos permitirn almacenar los
textos y documentos del comentario en cuestin, as como una
indicacin del rol que tena el usuario que realiza el comentario, ya
que no es igual un comentario realizado por un tutor que uno
relacionado por un aprendiz.
227
La clase Document ser una clase simple con propiedades de tipo de datos
sobre su nombre (propiedad nameOfDocument), URI (propiedad
URIofDocument) y mltiples posibles URIs alternativas (por medio de la
propiedad alternativeURI).
La clase Rol es una clase definida por sus elementos, es decir, consta de una
enumeracin de elementos. Se ha definido en ella los posibles roles que
pueden participar en el foro:
Rol [Expr. 6.22]

{LearnerRole, TutorRole, TechnicalSupportRole,
FacilitatorRole, ContentAuthorRole, GuestRole}
De esta forma, en la figura 6.18 podemos ver las propiedades principales de

las clases que nos permiten definir los foros.
Fig. 6.18. Propiedades principales de la ontologa de definicin de foros
Como apreciamos en la figura 6.18, el elemento principal de los foros es el

comentario con estructura de rbol (clase TreeComment). Los comentarios
iniciales de los foros estarn relacionados con un objeto de la clase
ForumThread, que a su vez estar relacionado con un objeto de la clase
Forum, de forma que un objeto Forum pueda tener mltiples objetos
228
ForumThread. Tambin podemos observar sus relaciones con el Rol que

gener el comentario y con el posible documento anexado.
6.7 Conexin de las tres ontologas

En este punto veremos los puntos de unin entre las tres ontologas
especificadas anteriormente para generar una nica ontologa que cubra
todos los aspectos generales de una experiencia educativa sobre la que
queramos potenciar la interoperabilidad. Aunque lo hemos visto a lo largo
de las descripciones de las subontologas, los puntos de conexin son:
Conexin de los contenidos estticos con las interacciones

alumno-sistema. La subontologa de contenidos estticos y la de
interaccin alumno-sistema se relacionan al definir la clase
AssessmentActivity como una subclase de la clase LeafActivityItem
de tipo SCORMSCO. De esta forma algunas de las instancias de la
clase SCORMSCO podrn ser actividades de evaluacin.
Esta relacin sigue la filosofa que se especifica en SCORM, con

diferencia que aqu toda instancia de la clase AssessmentActivity es
un SCO y no puede ser un Asset. De este modo cuando un autor
quiere introducir un punto de interaccin alumno-sistema, como
puede ser un test, lo hace en la definicin de los contenidos estticos,
aadiendo objeto de la clase SCORMSCO especial que ser la
actividad de evaluacin, es decir, un objeto de la clase
AssementActivity.
Conexin de la ontologa de contenidos estticos con la ontologa

de interaccin entre usuarios. La ontologa de contenidos estticos
y la de interaccin entre usuarios (foros) se relacionan por medio de
la propiedad relatedTo, que relaciona un foro con una instancia de la
clase LearningActivity (que puede que sea un cluster o un elemento
terminal).
No se especifica en la ontologa si los distintos foros de la

experiencia educativa se crean al principio con el contenido esttico
del curso o si se pueden crear a peticin de un usuario en el periodo
de imparticin. De esta forma damos mayor flexibilidad ya que
puede haber casos en que se quiera un slo foro o un conjunto
definido antes de la imparticin y otros casos en que los foros se dan
de alta durante la ejecucin del curso.
229
Conexin de las dos subontologas de interacciones. Estas dos

ontologas se pueden relacionar entre s por medio de la ontologa de
contenidos estticos, de modo que un objeto de la clase
AssessmenItem que sea un SCORMSCO puede estar relacionado con
un Forum por medio de la propiedad relatedTo de una instancia de
la clase Forum.
De esta forma las tres subontologas se unen en una nica que define los tres
bloques definidos al principio del captulo (ver Fig 6.1).Una de las ventajas
de unir las ontologas radica en que nos permitir, por ejemplo, que cuando
hagamos bsquedas en repositorios, podamos localizar la actividad de
aprendizaje que tiene un foro sobre el que se trata un tema que me interesa,
o que cuando importemos un curso importemos tambin los foros de una
explotacin anterior, lo que nos permitir aumentar la base de
conocimientos del curso.
Adems, de esta forma la interaccin de los actores no queda fuera de lo que

se entiende como la informacin a exportar de un curso y esta informacin
nos servir para realizar bsquedas inteligentes a los foros relacionados, lo
cual no es posible con los desarrollos actuales, ya que los foros son una
herramienta que nace y muere en una nica imparticin del curso.
6.8 Conclusiones de la especificacin

Como hemos visto a lo largo del captulo hemos especificado una ontologa
utilizando lgica descriptiva para facilitar la interoperabilidad de los objetos
educativos. La especificacin en lgica descriptiva se ha realizado de forma
que su transformacin a OWL DL es directa como veremos en el captulo
siguiente.
Al limitar nuestra lgica a OWL DL nos ha obligado a prescindir de las

aserciones de reglas, pero no nos ha limitado en ningn apartado, ya que
como hemos visto no hemos necesitado ninguna regla para definir los
conceptos necesarios para facilitar la bsqueda y comparticin de objetos
educativos. Son mayores los beneficios, ya que es el lenguaje OWL DL el
que se est utilizando mayoritariamente para la web semntica y es el que
tiene razonadores optimizados.
El hecho abordar la especificacin en tres bloques diferenciados ha

permitido realizar un enfoque modular que aporta claridad a la
especificacin, ya que la divisin se ha realizado entre los contenidos
estticos, las interacciones alumno-sistema y por ltimo las interacciones
230
entre los distintos usuarios. Como ya hemos visto en el captulo, esta

divisin pretende separar los distintos enfoques de aprendizaje: el
cognoscitivista, el conductista y el constructivista. Aunque se ha abordado
de forma modular se ha tenido en cuenta en todo momento el conjunto,
indicando los puntos de unin entre las tres ontologas que hace que tenga
coherencia el conjunto.
En cada uno de los elementos de la ontologa se ha preferido seguir, en caso

de que existan, conceptos de las distintas normas, especificaciones y
modelos de referencia como son ADL SCORM[ADL04a][ADL04b], IMS
QTI [QTI06][QTI06b], IMS CP[IMS04] e IEEE 1484[IEEE05][IEEE02] e
IEEE RDCEO[IEEE02]. Ninguna de las especificaciones cubre totalmente
la ontologa propuesta, por lo que se ha ido indicando qu partes de cada
una se han ido siguiendo en cada caso. Para seguir estas normas ha sido
necesario extraer los conceptos de las mismas, ya que la mayora de las
normas estn definidas en XML y llevan documentacin explicativa donde
se indican las distintas restricciones y comportamientos, no estando ninguna
descrita en un lenguaje ontolgico para la web. La ventaja de representar la
informacin en lenguaje ontolgico radica en que podr introducirse en la
web semntica para que la informacin sea explotada por los agentes
inteligentes, que puedan ayudar a los usuarios a realizar bsquedas ms
eficaces y mejores para localizar objetos educativos,
Sin embargo, dado el enfoque novedoso de la ontologa, ya que no se ha

encontrado un enfoque similar en ninguna de las ontologas estudiadas, se
ha tenido que ampliar los conceptos de los estndares actuales para permitir
la bsqueda y localizacin de objetos educativos de una forma ms eficaz.
Es el caso de las relaciones directas entre las actividades de evaluacin y los
objetivos de aprendizaje, o toda la implementacin de ontologa para las
interacciones entre usuarios, como son los foros y comentarios. Estas
ampliaciones facilitan que la informacin introducida a travs de la
interaccin de los usuarios durante una experiencia educativa se almacene e
indexe de la misma forma que los contenidos estticos. Esta informacin
introducida es una fuente para generar una base de conocimiento que
podramos aprovechar para localizar un objeto educativo o incluso para
utilizar en otras imparticiones del curso. De esta forma podemos ir
enriqueciendo un repositorio de experiencias educativas con la base de
conocimiento generada por medio de la interaccin de los usuarios en los
foros. Este extremo nos permitir ampliar las bsquedas, como ya se ha
indicado a lo largo de este captulo.
231
Tras realizar la especificacin formal de la ontologa, en el captulo

siguiente realizaremos una validacin de la misma, es decir, la traduciremos
directamente al lenguaje OWL DL y realizaremos una prueba de concepto,
donde validaremos el sistema y veremos ejemplos del funcionamiento de las
distintas partes de la arquitectura.
232
Captulo 7: Validacin de la
Ontologa OWL DL
y Resultados
7.1 Introduccin
Como se explica en los primeros captulos de esta Tesis, actualmente la
informacin publicada en la web no contiene informacin semntica para
que pueda ser tratata por agentes inteligentes, y por tanto las bsquedas que
se pueden realizar en esta informacin publicada se basa en bsqueda de
palabras clave. Actualmente, con el desarrollo de la web semntica, van
apareciendo algunas ontologas que pretenden subsanar la carencia de
informacin entendible por los futuros agentes.
Por otro lado, en el campo de la teleeducacin se est empezando a adoptar

el paradigma de la reutilizacin, tras haber experimentado los altos costes de
233
la generacin de materiales desde cero. Para que tenga lugar la reutilizacin

de objetos educativos, tenemos que ser capaces de publicar y buscar dichos
objetos de la forma ms sencilla y automtica posible. Es aqu donde entra
la web semntica y la necesidad de generar ontologas en el campo de la
teleeducacin, que nos faciliten la interoperabilidad de los recursos
educativos, preferentemente basndonos en estndares y especificaciones ya
existentes.
Otra de las carencias de las iniciativas de teleeducacin para la

interoperabilidad es el desaprovechamiento de las interacciones de los
usuarios de una experiencia educativa para enriquecerla, de forma que se
pueda almacenar esa informacin para otras ocasiones, e incluso utilizar
como elemento para la realizacin de bsquedas.
La ontologa especificada en esta Tesis pretende suplir estas carencias, ya

que dicha ontologa facilita la interoperabilidad al estar elaborada para la
web semntica. Incluye tambin conceptos novedosos hasta el momento
como las interacciones entre los usuarios de una experiencia educativa. Esta
ontologa, apoyada en la arquitectura propuesta para su explotacin,
pretende adems facilitar el uso de la informacin por parte de agentes
inteligentes. Gracias al sistema definido, los usuarios interesados en buscar
recursos educativos para su reutilizacin podrn apoyarse en agentes
inteligentes que les facilitarn resultados ms precisos, completos y
organizados.
Tras desarrollar los puntos principales de la Tesis, que han sido la

especificacin de la ontologa que potencie la interoperabilidad de los
recursos educativos para la teleformacin, y el diseo de una arquitectura
basada en la web semntica para soportar el uso de esa ontologa por
agentes inteligentes; se proceder en este captulo a validar el sistema
implementando algunas de las partes del mismo. Esta prueba de concepto,
seguir los siguientes pasos:
Descripcin en OWL DL de la ontologa global, tratando con

especial atencin los conceptos relacionados con los foros. Esta parte
se basar en el captulo anterior, dentro del cual se realiza la
especificacin de la ontologa. Para realizar este paso se estudiaran
distintas posibilidades y herramientas que facilitan esta labor de
transformacin, cuando ya est especificada una ontologa en
lenguaje lgico no web y se pretende traducir a OWL.
234
Importacin a nuestro sistema de datos reales de foros de

experiencias formativas on-line siguiendo la ontologa especificada
en el captulo anterior. Los datos que se importarn sern una
recopilacin de informacin relacionada con foros pertenecientes a
experiencias educativas de los ltimos aos. Este tipo de extraccin
de informacin de los foros no se realiza en los sistemas actuales de
formacin on-line, ya que es una informacin no aprovechada que
desaparece cuando se acaba una experiencia educativa. Para realizar
esta importacin nos basaremos en Jena, una infraestructura
desarrollada en Java orientada a facilitar el trabajo para la web
semntica.
Modelizacin de un agente inteligente, que realice bsquedas,

alimente su base de datos y realice tambin inferencias. Para realizar
este modelo se compararn los distintos motores de inferencia para
OWL DL para elegir el ms adecuado para nuestra validacin.
7.2 Generacin de la ontologa propuesta en OWL

A lo largo del captulo 6 se ha especificado la lgica de la ontologa
propuesta, de forma que slo nos resta implementarla en OWL, comprobar
que cumple las restricciones OWL DL y validarla. Por desgracia, la novedad
de los lenguajes utilizados hace que no existan muchas herramientas para
este fin y las que existan sean en su mayora componentes de proyectos de
investigacin que se encuentran an en una fase de pruebas.
Por tanto, para plasmar la ontologa en OWL DL se han estudiado las

herramientas de autor para generacin de ontologas ms importantes y
referenciadas en el campo de estudio. Dichas herramientas son:
1. Generacin directa por medio de un editor de texto o editor XML

estndar. Esta opcin se basa en utilizar herramientas de capas de la
web semntica inferiores, como puede ser XMLSpy para generar un
documento OWL.
2. Altova SemanticNetworks 2006, la nica herramienta comercial

existente que ha sido desarrollada por los creadores de XMLSpy,
uno de los editores de XML ms utilizados. Su objetivo es facilitar a
los autores de documentos RDF y OWL la elaboracin y
modificacin sintctica de los mismos.
235
3. SWOOP 2.3 beta 3, herramienta opensource para el diseo y

comparticin de ontologas OWL DL en la web.
4. Protg 3.1.1, herramienta que permite el diseo de ontologas de

forma generalizada y dispone de un plug-in para particularizarlas a la
lgica OWL.
A continuacin explicaremos por encima sus caractersticas y realizaremos

una evaluacin subjetiva sobre los entornos.
7.2.1 Generacin directa

Esta opcin realmente no es el uso de una herramienta de generacin de
ontologas, sino el uso de herramientas de ms bajo nivel para generar los
documentos. Se puede comparar con el uso del bloc de notas de Windows
para generar documentos html. Si bien esta opcin es vlida para ejemplos
sencillos y permite modificaciones muy puntuales, se descart desde el
principio debido a la complejidad de generacin y depuracin con esta
tcnica. Esta dificuldad proviene del hecho de que, al no ser herramientas
que entiendan la sintaxis de las ontologas, se fuerza al usuario a
preocuparse ms por la sintaxis que por la ontologa en s. Adems, no
disponen de herramientas directas de validacin y chequeo de las
ontologas, as como aadidos para realizar pruebas de inferencias. Sin
embargo estas herramientas son importantes, ya que la mayora de
herramientas de generacin de ontologas se construyen sobre stas, debido
a la estructura en capas de la web semntica.
7.2.2 Altova SemanticNetworks 2006

Esta herramienta est desarrollada en el 2006 por la compaa que
desarroll el famoso XMLSpy para el desarrollo de documentos XML
[WWW52]. Para evaluarlo, al ser una herramienta propietaria se ha utilizado
la licencia gratuita de 30 das que se ofrece en la descarga. Es una
herramienta visual diseada para documentos RDF, RDFS y OWL (Ver Fig.
7.1).
236
Fig. 7.1. Altova SemanticNetworks
Destaca de la herramienta que es muy intuitiva, probablemente debido a que

se basa en la experiencia de otros productos de la compaa. Adems consta
de una ayuda bastante completa, y de una opcin de visualizacin grfica
(como podemos ver en la figura 7.1) muy descriptiva.
Sin embargo es una herramienta muy orientada a RDF que dibuja

sintcticamente todo como relaciones entre entidades (por ejemplo, una
propiedad est relacionada por medio de range con la clase rango de la
misma) sin permitir ampliar la ontologa ni realizar inferencias.
Adems, su estructuracin en rbol se basa en poder desplegar todos los

grafos RDF que contiene el recurso que desplegamos, sin realizar gran
distincin (slo un pequeo grfico en la relacin y un recuadro con borde
distinto si es clase, instancia o propiedad) entre los casos en que es una
relacin de herencia (subclase) o es una propiedad, o cualquier otra relacin.
No chequea tampoco si una relacin ya se ha mostrado en la estructura de
237
rbol, por lo que se puede llegar a un bucle de relaciones ya que podemos

repetirla si hay propiedades inversas.
Tambin se ha de de destacar que aunque permite revisar sintcticamente

OWL en las versiones lite y DL, no est diseado para realizar ningn tipo
de inferencia ni para conectarse directamente con un motor de inferencia.
Todas estas caractersticas hacen que no haya an empresas que se hayan

decantado por esta herramienta, mientras que las herramientas de XML de la
compaa, como XMLSpy s son utilizadas en muchos casos. Si bien se
evalu la versin 2006, se ha comprobado que la versin 2007 no incluye
grandes variaciones.
7.2.3 SWOOP 2.3 beta 3

SWOOP (Semantic Web Ontology Overview and Perusal) [WWW53] es
una herramienta opensource desarrollada a partir del 2004 por MINDSWAP
(Mariland INformation and Network Dynamics lab Semantic Web Agent
Project) y que est actualmente (desde marzo 06) en su versin 2.3 beta 3.
Se basa en un interfaz web (Fig 7.2), es decir, SWOOP acta como un

navegador y permite navegar entre las clases (aprovechando las URIs de los
recursos para acceder a ellos).
Fig. 7.2. SWOOP
238
En la figura 7.2 podemos apreciar el interfaz web grfico. Al ser desde el

principio una herramienta diseada para OWL DL, diferencia totalmente
entre clases, propiedades e individuos, teniendo a la izquierda una estructura
en rbol para la navegacin entre los recursos, separndolos en tres pestaas
segn sean clases, propiedades o individuos. Las estructuras en rbol se
generan en funcin de las relaciones de herencia entre las clases y
propiedades.
Fig. 7.3. Estructura de navegacin por los recursos
Por ejemplo, en la figura 7.3 podemos apreciar que la clase Answer es una
especializacin de la clase Comment. La navegacin es sencilla, ya que la
estructura en rbol nos sirve de men para buscar y mostrar a la derecha la
clase, objeto o instancia que deseemos tratar.
SWOOP permite adems, editar directamente los recursos por un sistema

parecido a wiki [KAL04], de forma que realiza un control de versiones del
recurso. La forma de editar los recursos est muy orientada a la sintaxis de
OWL, en lugar de estar orientado a un sistema general de representacin del
conocimiento por medio de ontologas [KAL05].
SWOOP est orientado al desarrollo colaborativo de ontologas, de forma

que se puedan realizar pequeas ontologas entre distintos autores y
conectarlas entre s por medio de referencias o importaciones. Para facilitar
esto dispone de un plug-in (denominado Annotea) para compartir
anotaciones entre distintos autores sobre el mismo recurso, as como un
sistema de control de versiones realizado desde un servidor de una ontologa
donde guarda todos los cambios realizados y permite actualizar la ontologa
para obtener la ltima versin.
239
7.2.4 Protg 3.1.1

Prteg es una herramienta opensource que permite la creacin y edicin de
ontologas as como la creacin de bases de conocimiento. Est desarrollada
principalmente por Stanford Medical Informatics, con la colaboracin de la
Universidad de Manchester y cuenta con el apoyo de la National Library of
Medicine. Aunque existan versiones desde 1995, Protg 2000 fue la base
del desarrollo actual.
Protg dispone de dos formas de modelar ontologas:
Protg-Frames editor, que permite trabajar con un modelo de

frames compatible con OKBC [CHA98]. No evaluaremos esta forma
de operar al no ser la utilizada en la Tesis.
Protg-OWL (Figura 7.4) editor, que es el preparado para el diseo

de ontologa para la web semntica, basados en OWL o SWRL. Este
editor es realmente un plug-in instalado sobre la versin de frames,
que es con la que trabaja internamente Protg.
Fig. 7.4. Protg-OWL 3.1.1
240
En la figura 7.4 podemos apreciar el espacio de trabajo de la aplicacin

Protg, con tambin una estructura en rbol para clases, instancias y
propiedades como ocurra en SWOOP, pero con un interfaz ms amigable a
la hora de editar un recurso en particular, ya que incluso representa las
restricciones con operadores de lgica matemtica.
Todas las caractersticas evaluadas a partir de este punto sobre Protg se

refieren al editor de OWL, ya que el objetivo de la herramienta es modelar
una ontologa en este lenguaje.
Como caracterstica ms destacada tenemos sus aos de desarrollo continuo

as como la comunidad de usuarios y desarrolladores que arrastra el
proyecto (en julio 2006 ms de 52.000 usuarios registrados y ms de 2.500
usuarios apuntados a la lista de discusin de Protg-OWL).
El hecho que haya gran cantidad de desarrolladores, y que se haya facilitado

un estndar para aadir plug-ins a Protg, hace que exista una gran
cantidad de plug-ins para muchas utilidades, de forma que no sea necesario
tenerlos todos, sino slo importar y ver los que nos interesen. Por ejemplo,
en la figura 7.5 podemos ver los plug-ins utilizados en nuestro caso
(representados como pestaas), para realizar bsquedas en la sintaxis RDF
(pestaa Queries) y para visualizar las ontologas (pestaa Jambalaya).
Fig. 7.5. Plug-ins en Protg
La visualizacin de los recursos es mucho ms visual que en SWOOP,

separando completamente las clases de las instancias, las propiedades y las
restricciones (Ver Fig 7.6).
241
Fig. 7.6. Ejemplo de edicin visual de una clase
Como SWOOP, permite la conexin directa con razonadores, pero en este

caso separa entre el modelo que hemos diseado y el inferido (aadiendo las
inferencias que ha dado el razonador). Esta separacin se da a nivel de
herramienta, de modo que los plug-ins (por ejemplo, de visualizacin)
pueden utilizar ambos modelos, como se muestra en la figura 7.7.
Otra ventaja de Protg, es la presencia de templates y patrones de diseo

para generacin de algunas acciones que se repiten mucho en la definicin
de ontologas (y pedidos por la amplia comunidad de usuarios y
desarrolladores de la herramienta). Por ejemplo, generar clases disjuntas
directamente, generar enumeraciones, listas, etc.
242
Fig 7.7. Ontologa diseada e inferida
7.2.5 Comparacin de las herramientas

Para realizar este punto nos basamos en los resultados comparativos de la
tabla 7.1.
En primer lugar descartamos Altova SemanticNetworks por su poca

orientacin hacia desarrollo de ontologas OWL, as como su poca
conectividad con motores de inferencia (razonadores). Suponemos que en
versiones ms maduras incluir estas propiedades.
Caracterstica SemanticNetworks SWOOP Protg

(versin OWL)
Evaluacin objetiva
Multiplataforma NO SI (Java) SI (java)
Cdigo abierto NO SI (MIT SI (Mozilla PL
license) license)
Freeware NO SI SI
Conexin con NO SI (va HTTP) SI (va HTTP)
razonadores
API para utilizar NO SI SI
Orientacin a Baja Total Total (OWL,
OWL SWRL)
Cantidad de plug NO <5 >20
ins
243
Visin abstracta Baja Media (todas Alta (visin

de la base de (representacin las relaciones conceptual)
conocimiento sintctica) se ven
iguales)
Evaluacin subjetiva
Facilidad de Alta Alta
Media (plug-
instalacin ins algo ms
costosos)
Facilidades para Alto (ayuda en el Bajo (videos Alto (tutoriales
aprender el programa) de ejemplo en completos)
manejo la web)
Facilidad de uso Alta baja media
Comunidad de Bajo (compaa) Medio Alto
desarrolladores
implicados
Tabla 7.1. Comparativa de herramientas de autor de ontologas
En la Tabla 7.1 se han comparado caractersticas objetivas y subjetivas. En

las objetivas podemos apreciar que SWOOP y Protg estn bastante
igualadas, ya que son plataformas onpensource, muy orientadas al uso de
ontologas en OWL y compatibles con el uso de razonadores. Protg
destaca al tener ms ampliaciones, y al permitir trabajar con ontologas en
un nivel de abstraccin mayor, de forma que no es necesario ni conocer la
sintaxis de OWL.
Sin embargo en la evaluacin subjetiva se aprecia que Protg obtiene

mejores resultados, al ser ms fcil e intuitiva de usar, y estar respaldada por
una comunidad de desarrolladores ms amplia. Slo Protg es un poco ms
complicada a la hora de instalar ampliaciones distintas a las estndar,
aunque actualmente incluye en la versin de instalacin la mayora de
ampliaciones recomendables para el trabajo con OWL.
Por tanto, entre SWOOP y Protg elegimos Protg, ya que es una

herramienta ms visual, con ms recursos de ayuda y con una comunidad de
desarrollo y deteccin de errores considerable que hace que el producto sea
un producto bastante estable. SWOOP tiene un grado de madurez ms bajo
que Protg, como se indica en [RUT05].
7.2.6 Generacin de la ontologa

Hemos seleccionado la herramienta Protg como la ms idnea para
traducir a OWL DL la ontologa para teleeducacin especificada por medio
244
de lgica descriptiva en el captulo anterior. Para realizar dicha traduccin,

en la que generaremos un documento OWL DL que describa las clases de la
ontologa, es decir, la informacin no relativa a instancias (TBox) de la
misma.
La ontologa de las clases (TBox) se genera siguiendo los axiomas

presentados en el captulo de especificacin de la ontologa, siguiendo los
siguientes pasos cclicamente en un proceso de refinamiento iterativo.
GENERACIN
NO
DE CLASES
NO
DEFINICIN DE
CONSISTENTE?
PROPIEDADES
SI
GENERACIN
DE AXIOMAS
CUMPLE
EXPECTATIVAS?
CHEQUEO DE SI
CONSISTENCIA
FIN
Fig 7.8. Procesos de refinamiento iterativo
En la figura 7.8 podemos ver el esquema del proceso de refinamiento

iterativo que consiste en:
1. Generacin de las clases primitivas y su relacin jerrquica
directa. Siguiendo la gua de [NOY01], se deja como clases los
conceptos que vayan a ser tratados como tales e la ontologa y se
colocar luego como instancias el nivel ms pequeo de
granularidad y que representa un elemento real y no un concepto en
la ontologa. La definicin de estas clases se realiz ya en la
especificacin de la ontologa.
245
2. Definicin de las propiedades de las clases, basndonos en las

posibles necesidades (en este caso de bsquedas y de relacin entre
objetos) del sistema. De nuevo fue parte de la especificacin.
3. Generacin de axiomas y las clases definidas por medio de los

mismos (como es el caso de TopTreeStructure, RootItem, LeafItem,
ClusterItem). Es decir, despus de ver el sistema de clases es cuando
aparece la necesidad de generar axiomas que los definan y restrinjan.
4. Chequeo de la consistencia de la ontologa. Chequear la ontologa

significa asegurar que no existen contradicciones en la misma y ver
las relaciones de herencia que se pueden inferir de las aserciones.
Son operaciones equivalentes a las descritas en el apartado 2.6.4 del
captulo 3, donde se hablaba de los razonamientos en la lgica
descriptiva. Para los chequeos de la ontologa se han utilizado tanto
el razonador Racer 1.9 como Pellet 1.3 beta 2. Si el chequeo muestra
incongruencias, volveremos a repasar desde el primer punto. En caso
de ser positivo, estudiaremos el conjunto para ver si cumple los
requisitos que esperamos (es decir, que representa fielmente los
conceptos que deseo describir y utilizar) y si no es as volveremos al
inicio para aadir nuevas clases, propiedades o axiomas en ese
orden. Si tras chequear la consistencia la ontologa cumple nuestras
expectativas damos el proceso por concluido.
Este proceso iterativo se ha aplicado para las siguientes ontologas, que son
en su conjunto la ontologa global de e-learning:
I. Ontologa de la estructura de rbol, con la consiguiente

comprobacin de que las propiedades estaban correctamente definidas
y que se podan inferir padres, ancestros y elemento raz de un rbol.
II. Ontologa de los contenidos estticos, introduciendo los conceptos

de estructura de rbol. Una vez pasada a owl y chequeada no se ha
utilizado ms, ya que la parte sobre la que realizaremos la prueba de
concepto es otra.
III. Ontologa de interacciones entre el alumno y el sistema, basndose

en la ontologa de contenidos estticos (ya que son una especializacin
de la clase ScormLeafLearningActivity), introduciendo las listas de
tipo rdf:List necesarias para su implementacin. Se genera y se
chequea su consistencia.
246
IV. Ontologa de las interacciones entre usuarios. Esta ontologa se ha

unido con la ontologa de la estructura de rbol y luego se ha generado
la conexin correspondiente (mediante la propiedad relatedTo) con la
estructura de contenidos estticos.
En este punto destacamos la generacin de la clase enumerada Role.

La razn por la que esta clase se define por medio de sus instancias es
la necesidad de limitarse a OWL DL, por lo que las propiedades slo
pueden ser de tipos de datos o de objeto, por lo que cuando definamos
el rol que tiene en el curso el autor de un comentario, podamos
relacionarlo con una instancia de la clase Role.
Hemos de destacar que la ontologa se genera con denominaciones en

ingls, para facilitar la publicacin de resultados en foros internacionales. La
URI que sobre la que se generar la TBox ser:
http://dcom.upv.es/owl/rorollo/tesis.owl [Expr. 7.1]
Aunque lo ms recomendable es que esa URI fuera una URL que nos
permitiera obtener el archivo .owl (es decir, que con un navegador
pudiramos acceder al archivo owl con esa URL), no es necesario, ya que
slo indica un identificador nico para la ontologa.
El resto de ontologas creadas se generarn sobre URIs que compartirn la

misma raz, y que contendrn las instancias de los distintos foros:
http://dcom.upv.es/owl/rorollo/ [Expr. 7.2]
Aunque podramos haber asignado la misma URI a todas la ABox (incluso

que fuera la misma que la de la TBox), para aclarar mejor los ejemplos
preferimos separar las URIs y realizar importaciones para unir las ontologas
en una base de conocimientos nica.
7.2.7 Chequeo de las ontologa

Para realizar el chequeo de las ontologas se sigue el siguiente esquema (Ver
Fig.7.9):
247
DIG/HTTP RAZONADOR 1
INTERFACE
INTERFACE
(1) CONSISTENTE?
HTTP
HERRAMIENTA
DIG
DE AUTOR (2) CLASIFICAR
DIG/HTTP RAZONADOR 2
Fig. 7.9. Esquema de trabajo para el chequeo de ontologas
Como podemos ver en la figura 7.9, tras desarrollar la ontologa en la

herramienta de autor, la misma herramienta ofrece una conexin va
DIG/HTTP con razonadores que estn dando el servicio de chequeos de
ontologas que estn a la espera a modo de servidores HTTP.
Se aprovecha la ventaja de conexin por medio de DIG/HTTP [BECH03]

que nos ofrece Protg para activar dos razonadores (Racer y Pellet) como
servidores HTTP en los puertos 8080 y 8081 de nuestra mquina de
pruebas. Se describirn las caractersticas de los razonadores ms adelante.
En cada momento de comprobacin de la ontologa se realizan dos pasos:
Chequeo de consistencia de la ontologa, es decir, ver que no

hemos definido ninguna clase que no pueda tener nunca instancias.
Clasificacin de las clases de la ontologa. Esto hace que el

razonador vea si puede inferir ms relaciones de herencia o
equivalencia entre clases que los indicados por el autor.
En la figura 7.10 podemos ver ejemplos de chequeos de consistencia y

clasificacin.
248
Fig 7.10. Chequeo y Clasificacin con distintos razonadores
Como ltimo paso, las ontologas finales OWL se chequean a su vez por
medio de la versin web de Pellet [WWW54], para corroborar el nivel de
OWL utilizado (Lite, DL o Full). En la Fig 7.11 vemos los resultados de
chequear nuestra TBox. Se ratifica que cumplen la sintaxis OWL DL. La
razn por la que se chequea la ontologa como archivo .owl es la indicacin
de algunos autores [RUT05] que constatan que el interfaz DIG no permite
indicar restricciones cardinales sobre propiedades de tipo de datos. Esto
puede hacer que, utilizando DIG, se den ontologas como consistentes
cuando puede que haya alguna inconsistencia. De todas formas nuestra
ontologa no utiliza este tipo de restricciones.
249
Fig 7.11. Validacin OWL de Pellet para nuestra TBox
Como vemos en la figura 7.11, el resultado de enviar nuestro fichero OWL

al chequeador Pellet nos devuelve que es del tipo DL (OWL Species=
DL). Pellet indica tambin qu restricciones tendramos que eliminar para
convertir el fichero en OWL Lite.
Tras realizar esta ltima comprobacin concluimos que la ontologa

plasmada en OWL DL no tiene incongruencias y adems cumple con todas
las restricciones definidas en el captulo de especificacin de la ontologa. A
partir de este punto realizaremos una prueba de concepto que permita
demostrar que la ontologa especificada y la arquitectura propuesta son
vlidas para los objetivos planteados, es decir, que se puede extraer la
informacin de las experiencias educativas de forma correcta y que los
agentes inteligentes pueden utilizar dicha informacin para encontrar los
recursos educativos adecuados.
7.3 Importacin de los datos reales de foros de

experiencias formativas on-line
En este apartado describiremos con detalle el sistema diseado para
importar a nuestra ontologa propuesta la informacin sobre los foros de las
experiencias formativas on-line. Detallaremos el origen de la informacin
sobre foros reales, el entorno de desarrollo del sistema, algunos puntos
importantes de la programacin y por ltimo comentaremos los resultados
contenidos. Por tanto, en este apartado emularemos el subsistema extractor
250
de informacin semntica del publicador propuesto en nuestra arquitectura

diseada en captulos anteriores (ver Fig. 7.12),
BUSCAR (K1, TBox)
DHT SEMANTICA
AGENTE V = OWL URL
OWL
OWL URL
PUBLICADOR
SEMNTICOS
OWL
ALMACEN INFORMACION
SEMNTICA
.OWL
LO-A LO-B LO-C

Fig 7.12. Parte de la arquitectura emulada en este apartado
Como se indica en la figura 7.12, la parte que vamos a implementar es la de

extraccin de informacin semntica de una experiencia educativa ya
existente, de forma que esta informacin pueda ser publicada en la web
semntica y utilizada por los agentes inteligentes.
251
7.3.1 Origen de los datos

La informacin utilizada para la comprobacin de las ontologas proviene de
foros reales de experiencias formativas on-line almacenadas en el Centro de
Formacin Permanente (CFP) de la Universidad Politcnica de Valencia.
Se utilizar un conjunto de foros terminados hace varios aos, siendo todos

de ediciones distintas del mismo curso (es decir, foros de cursos realizados
con los mismos contenidos estticos, pero generados en distintas
comunidades virtuales). En total han sido 31 ediciones distintas las
utilizadas. Las identificaremos por su identificador nico de comunidad
virtual en el sistema de informacin del CFP.
Respecto a la implementacin que se ha realizado en el CFP de los foros en

el sistema destaca lo siguiente:
Un curso puede tener mltiples foros, pero no se contempla el

concepto de Thread. Nosotros consideraremos, por tanto, a cada foro
como con un nico Thread, cuyos datos completaremos con el
primer mensaje del foro.
Los mensajes de los foros no tienen por qu tener por obligacin

un ttulo del mensaje. Lo que haremos en los casos que no exista
ttulo ser poner los primeros 20 caracteres del texto a modo de
sindicacin. Los que tenga un ttulo mayor a 20 caracteres se les
recortar a 20 caracteres.
Los mensajes de los foros identifican a su autor directamente, no

por su rol. Esto lo resolveremos descubriendo el rol del autor y
colocndolo en la propiedad del rol.
El curso en cuestin est diseado para ser un curso que le cueste al alumno
unas 45 horas de dedicacin, y cuenta con talleres que han de entregar los
alumnos de forma individual, no en grupo. Esto debera forzar a los alumnos
a interactuar ms, al menos con el tutor del curso sobre los trabajos a
realizar.
El sistema de informacin del CFP se basa en una arquitectura de tres capas

(ver Fig. 7.13):
Capa de almacenamiento, siendo en este caso una base de datos

MS SQL Server 2003. En esta capa se almacenan todas las tablas
252
necesarias para el funcionamiento del sistema de informacin del

centro.
Capa de lgica de negocio, donde se implementan los conceptos

necesarios para el sistema (cursos, foros, matrculas, personas, roles,
etc) y los mtodos que interactan entre ellos y el interfaz de acceso
a la capa de almacenamiento. Esta capa est desarrollada en Java.
Capa de visualizacin, donde se presenta al usuario la informacin

y los elementos necesarios para que el usuario interacte con el
sistema. Tambin se encarga de instanciar elementos de la lgica de
negocio y ejecutar sus mtodos. Esta parte se ejecuta por medio de
JSPs y JSFs y se explota por medio de bateras de Apache-Tomcats.
CAPA DE PRESENTACIN
JSP/JSF
INSTANCIACIN
INVOCACIN MTODOS
CAPA DE LGICA DE NEGOCIO

JAVA
JDBC
CAPA DE ALMACENAMIENTO
MS SQL SERVER
Fig. 7.13. estructura de capas
La capa de almacenamiento se encuentra en un servidor dedicado, y cuenta

con otro servidor de reserva (no dedicado) que se actualiza peridicamente
con los datos del primero.
La capa de lgica y visualizacin se ejecutan sobre varios servidores

Apache que se encargan del reparto de contenidos por medio de HTTP y
HTTPS y una batera de Tomcats sobre varias mquinas (con sistemas
operativos linux o windows de forma indistinta), de forma que se
encuentran conectados a un nico Apache, pudiendo no ser la mquina que
ejecuta el Apache la que contiene al Tomcat.
253
7.3.2 Conexin con el origen de los datos

Para implementar la importacin a nuestro sistema se utilizan las mismas
herramientas que se utilizan en el CFP para programacin, lo que nos
facilitar la conexin con las fuentes utilizadas:
Programacin en java, lo que nos permitir reutilizar las clases de

lgica de negocio ya utilizadas en el centro. El resultado de la
programacin se integrar en el paquete cfp.poseidon.util, un
paquete de clases de java de tipo genrico que utiliza los paquetes
java de lgica de negocio del sistema.
El entorno de desarrollo Netbeans 5.0. Este entorno de desarrollo,

junto con el entorno de desarrollo Eclipse es el entorno de desarrollo
java utilizado en el centro. Es un entorno opensource que permite el
trabajo con la capa lgica y la capa de presentacin de forma
integrada.
Sistema de programacin colaborativa basado en el control de

versiones por medio de Subversion 1.3, integrado dentro del entorno
Netbeans. Toda la programacin del centro se lleva de forma
colaborativa, de forma que existe un acceso centralizado a las
fuentes, histrico de cambios y autores de los mismos.
La conexin con los foros del centro se har a travs de la capa de lgica de
negocio, por medio de clases ya programadas en el centro que son:
cfp.poseidon.core.Roles, clase que abstrae la informacin sobre los

roles disponibles por parte de un cliente.
cfp.poseidon.core.Comunidades, clase que abstrae el concepto de

comunidad virtual para la realizacin de una experiencia formativa.
A partir de l parten la informacin sobre contenidos estticos, foros,
chats, roles, fechas de actividad, etc...
cfp.poseidon.core.ComunidadBuscador, clase que nos permite

definir los parmetros de bsqueda en el sistema para buscar un
conjunto de comunidades virtuales.
cfp.poseidon.core.ComunidadForo, que se refiere a la informacin

necesaria para describir un foro de una comunidad.
254
cfp.poseidon.core.ComunidadForoMensaje, que se refiere a la

informacin de un mensaje perteneciente a un foro.
Todas estas clases, excepto la de cfp.poseidon.ComunidadBuscador, llevan

una clase de tipo Manager (por ejemplo, cfp.poseidon.mgr.RolesManager)
que nos permite conectar con la base de datos para acceder a instancias de la
misma buscadas nicamente por medio de campos de la tabla que lo
describe. Los buscadores, como ComunidadBuscador nos permiten buscar
por medio de caractersticas que afectan a ms de una tabla de la base de
datos.
7.3.3 Jena
Jena [WWW57] es una iniciativa de software abierto que cuenta con el
apoyo de HP Labs Semantic Web Program. Su primera versin Jena 1
(2001) se centraba en grafos y su transformacin a XML/RDF y en su
siguiente versin (Jena 2) aade por encima una capa para tratamiento de
ontologas (2003) y su transformacin a OWL. Jena permite adems
conectarse a Razonadores por medio de DIG [DICK04]. Por tanto Jena se
puede considerar como una infraestructura para trabajar con la web
semntica programando con Java.
Para implementar el paso a OWL de la informacin disponible se barajaron

las dos soluciones ms referenciadas a la hora de generar archivos OWL de
forma automtica cuando se dispone de una TBox ya definida:
1. Utilizar la API ofrecida por Protg para el manejo de ontologas.
2. Utilizar la API de Jena.
Ambas APIs estn desarrolladas en Java (lo que permite una integracin
directa con los sistemas del CFP), son opensource y comparten muchas
caractersticas comunes. Pese a utilizar Protg como herramienta de autor
para el manejo de ontologas de forma visual, se decide el uso de Jena
porque:
La API de Protg incluye mucha ms complejidad, ya que

permite realizar muchas ms acciones.
Para el interfaz con RDF/OWL la API de Protg utiliza Jena para

la transformacin.
255
Por tanto ser mucho ms ptimo utilizar directamente Jena que otra API
que se construye sobre Jena, ya que lo nico que realizaremos en esta fase
es la transformacin a OWL siguiendo la ontologa TBox comentada en
apartados anteriores.
Jena proporciona una API que nos permite leer y escribir en los formatos
XML/RDF [WIL03], N3 y N-Triples (formatos para grafos abreviados).
Adems dispone de un motor para poder buscar dentro de los documentos
RDF por medio de RDQL. Por ltimo ofrece tambin mecanismos para leer
y escribir en formato OWL. Esta ltima propiedad es la nica que
utilizaremos de Jena.
Jena trabaja con la clase Model, que es por donde podemos acceder a la
informacin del documento RDF. En el caso de ampliacin de RDF a
ontologas propiamente dichas (con clases, instancias, propiedades, etc), la
clase Model se especializa dando lugar a la clase OntModel, es decir, la
ontologa con la que est trabajando el sistema.
Adems trabaja con los conceptos (interfaces de Java para permitir

polimorfismo) que presentamos a continuacin (ver Fig 7.14):
Resource, entendido como cualquier recurso definible en RDF. Es

un interface de java de forma que los siguientes conceptos son
subclases de este interface.
OntClass, que representa una clase.
Individual, interface que representa una instancia de una clase.
Property, que representa la propiedad de relacin entre Resources.

Se divide en ObjectProperty (para propiedades con un objeto de tipo
instancia) y DatatypeProperty (para propiedades de tipo de datos).
Literal, que es un Resource que representa un elemento de tipo de

datos (xsd:).
Statement, que representa la frase que une un sujeto por medio de

una propiedad con un objeto.
256
Fig. 7.14. Herencia entre los interfaces de Jena 2
En la figura 7.14 podemos ver la relacin de herencia entre los distintos

interfaces de Jena 2, siendo las de color azul las relativas a OWL y las de
color morado las relacionadas con OWL propiamente dicho.
Jena 2 trabaja con muchos ms conceptos, pero como en nuestro caso no se

va a utilizar para definir la TBox (que ya se ha hecho con Protg) no es
necesario utilizar la API para indicar propiedades de tipo funcional,
restricciones, herencias, etc. En nuestro caso slo nos interesa la parte de
poblar las ontologas con instancias, es decir, crearlas y colocar valores a las
propiedades de las clases que ya estn definidas.
Los mtodos que ms utilizaremos son:
Sobre objetos de tipo Model
a) Resource createResource(java.lang.String uri), que

devuelve un objeto Resource que es uno nuevo si no exista
en el modelo con esa URI o el que existe si ya hay definido
alguno en con esa URI. En nuestro caso, al importar la
TBox tendremos ya definidas los objetos Resource de las
clases (que cumplirn tambin el interfaz de OntClass, pero
eso no nos afecta).
b) OntClass createClass (java.lang.String uri), que devuelve

la representacin de una clase. Este mtodo lo utilizaremos
solamente cuando necesitemos algn mtodo de la clase
OntClass que no se ofrezca desde el interfaz Resource.
257
c) Property createProperty(java.langString uri), que

funciona de forma parecida al mtodo anterior pero
devuelve ya un objeto que cumple el interfaz Property. Esto
nos ahorra convertir un objeto Resource a uno Property por
medio de
Resource res=...[creamos el Resource]. [Expr. 7.3]

Property p=(Property)res.as(Property.class)
d) Individual createIndividual (java.lang.String uri), que

igual que el anterior genera exactamente una instancia con
esa URI. Si la instancia con esa URI ya existe, no duplica
(esto nos servir para cuando obtengamos los Roles).
e) Literal createTypedLiteral(String value, RDFDatatype

dataType), que genera un literal con el valor y el tipo de
datos (datatype) que le digamos nosotros (en algunos caso
es suficiente colocar el objeto y Jena decide el tipo de
datos). Por ejemplo, para crear xsd:boolean o xsd:dateTime.
Para el tipo de datos xsd:string no es necesario y se puede
hacer directamente como vemos a continuacin.
f) Statement createStatement(Resource s, Property p,

RDFNode o), genera una frase con sujeto s, objeto o y
predicado p. Se utilizar este mtodo slo para las
propiedades de tipo de datos donde hemos de colocar como
objeto de la frase un Literal (RDFNode). Es equivalente al
mtodo de las instancias de Resource
(addProperty(Property p, RDFNode o). Jena no
proporciona mtodos directos para aadir propiedades de
tipo de datos a los objetos de la clase Individual.
g) Model add(Statement stm), mtodo que estamos obligados

a utilizar ya que cuando se crea un objeto de la clase
Statement no se aade al modelo hasta que no ejecutamos
este mtodo.
Sobre objetos de tipo Individual (son mtodos de su superInterface

Resource) utilizaremos:
258
a) Individual addProperty(Property p, Individual i), que

aade de nuestro modelo una relacin entre la clase que
ejecuta el mtodo y la instancia de Individual i por medio de
la propiedad (representada por la clase Property) p. El
mtodo realmente admite cualquier RDFNode (que admite
una clase Literal) y no slo instancias de Individual.
b) Individual addProperty(Property p, String s), que aade

una propiedad de tipo xsd:string.
Como podemos observar, Jena 2, aunque permite trabajar con ontologas y

conectar razonadores que implementen un interface determinado, sigue
estando muy orientado a RDF (trata de nodos, statements, grafos, etc). Sin
embargo, para la importacin es un punto poco importante, ya que la lgica
de la ontologa de clases (TBox) ha sido desarrollada por medio de otra
aplicacin y siempre ser ms rpido generar instancias usando RDF (lo que
significa trabajar a un nivel de abstraccin ms bajo nivel de abstraccin).
7.3.4 Programacin de la importacin

La importacin seguir el siguiente esquema (figura 7.15)
OWL
CAPA DE PRESENTACIN TBox
JSP/JSF
CAPA DE LGICA DE NEGOCIO EXTRACTOR/ OWL ABox

JAVA IMPORTADOR FOROS DE
UN
CURSO
JDBC
CAPA DE ALMACENAMIENTO
MS SQL SERVER JENA 2
DISCO
Fig. 7.15 esquema de la importacin de foros a OWL
Se programar un importador o extractor de informacin que utilizar la

API de Jena 2 y las clases mencionadas anteriormente de la capa de lgica
de negocio del sistema de informacin del CFP para introducir la
259
informacin de nuestra TBox, obtener los datos de los foros y

transformarlos a documentos OWL que almacenaremos en ficheros.
El exportador se basar en la clase java ExportaInteracciones.java, y los

pasos que se realizan por cada exportacin son:
1. Inicializacin del objeto OntModel y el objeto Ontology con su sus

espacios de nombres correspondientes.
[Expr. 7.4]
OntModel aBox =
ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM,null);
//generamos el namespace
aBox.setNsPrefix(tBoxPrefix,tBoxNs);
String
aBoxURI=rootURI+"community_"+this.getIdComunidad()+".owl";
aBoxNs=aBoxURI+"#";
//creamos la ontologia nueva
Ontology ontABox=aBox.createOntology(aBoxURI);
El nombre que se le da a la URI de la ontologa de cada comunidad

ser la raz comn ms el identificador de la comunidad dentro del
sistema del CFP. Por ejemplo, para la comunidad 128 tenemos:
http://dcom.upv.es/owl/rorollo/community_128.owl [Expr. 7.5]
2. Importamos la TBox.
[Expr. 7.6]
ontABox.addImport(aBox.createResource(tBoxURI));
//marcamos la ontologa importada para no importarla ms
veces
aBox.addLoadedImport(tBoxURI);
3. Insertamos en la ontologa los foros de la comunidad. Para

introducirlos los colocamos con URIs con prefijo ForumID_ y el
identificador nico del foro en el sistema.
[Expr. 7.7]
260
ComunidadForo f=...//cargamos de la base datos la informacin

del Foro
//generamos el foro y le aadimos propiedades
Resource res=aBox.createResource(tBoxNs+FORUM);
Individual ind
=aBox.createIndividual(aBoxNs+FORUM+"ID_"+f.getId(),res);
//ponemos el nombre del Foro
prop=aBox.createProperty(tBoxNs+FORUMNAME);
ind.addProperty(prop,f.getNombre()+"");
Para insertar el resto de instancias se utilizarn prefijos para las URIs

de ForumThreadID_ y TreeCommentID_, con los
identificadores respectivos en cada caso.
Adems, en cada caso se cargar, proveniente de la base de datos, la

informacin de la instancia correspondiente, como se ha hecho aqu
con la cfp.poseidon.core.ComunidadForo.
Es importante destacar en este punto que Jena, en la mayora de

mtodos que modifican la ontologa (aadir recursos, instancias,
propiedades de la mismas,...) devuelve el objeto instancia o recurso
al que estamos afectando. De esta forma tenemos una referencia al
mismo sin tener que buscar de nuevo en el modelo la instancia que
hemos colocado o la instancia a la que le hemos colocado una
propiedad. Esta propiedad es muy til y te permite encadenar
aserciones y tener siempre referencias a los recursos que ests
generando o modificando. Del mismo modo nuestros mtodos de
introducir foros, mensajes, etc, devuelven una referencia a la
instancia generada, para que podamos utilizarla en las siguientes
referencias.
4. Para cada foro encontramos el primer mensaje (el que no tiene

padre) y utilizamos sus datos para generar el ForumThread y el
RootItem correspondiente. En los mtodos correspondientes que
introducen en nuestra ontologa estos conceptos se aade
informacin sobre su padre, que llamaremos en cada caso con la
variable indIn (el objeto Forum para el ForumThread y el objeto
ForumThread para el RootItem), para poder colocarle la propiedad
correspondiente que los relaciona.
[Expr. 7.8]
261
ComunidadForoMensaje cfm=...//cargamos de la BBDD el primer

mensaje
Resource res=aBox.createResource(tBoxNs+FORUMTHREAD);
Individual ind
=aBox.createIndividual(aBoxNs+FORUMTHREAD+"ID_"+cfm.getId(),r
es);
//le colocamos el Forum (indIn) al que pertenece
Property prop=aBox.createProperty(tBoxNs+ISFORUMTHREADOF);
ind.addProperty(prop,indIn);
//de forma redundante, aceleramos busquedas poniendo
propiedad inversa
prop=aBox.createProperty(tBoxNs+HASFORUMTHREAD);
indIn.addProperty(prop,ind);
Para insertar el primer comentario del Foro (el objeto RootItem),

utilizamos un mtodo que coloca sus valores y entramos en un
mtodo recursivo que se encarga de ir insertando los hijos de cada
comentario del Foro hasta que se llega a comentarios sin hijos
(objetos de la clase LeafItems). En este caso se aade un lmite a la
recursividad para evitar bucles infinitos, llegando como mximo a
una profundad de foros de 18 niveles, ms que suficiente para la
mayora de foros (se considera una profundidad alta cuando se llega
hasta el sexto nivel).
5. Para cada comentario del foro lo generamos como Comment y le

colocamos sus propiedades como objeto Comment:
[Expr. 7.8]
//mtodo que genera el Comment y le coloca sus propiedades
//como comentario
ind=insertaMensaje(cfm);
//lo relacionano con su ForumThread (indIn)
prop=aBox.createProperty(tBoxNs+ISFIRSTITEMOF);
ind.addProperty(prop,indIn);
//coloco la propiedad inversa para acelerar busquedas
prop=aBox.createProperty(tBoxNs+HASFIRSTTREEITEM);
indIn.addProperty(prop,ind);
//metodo recurso para meter sus hijos y colocar las
//propiedades como TreeItem
insertaHijos(cfm,ind,profundidad);
Tambin habr que extraer el texto del comentario e insertarlo como

una de las propiedades. Se insertan tambin los literales de fechas y
que se inserta una propiedad de tipo objeto que es el Rol del autor:
262
[Expr. 7.9]
...
//pongo la fecha de creacion ej 2006-03-17T00:00:00
prop=aBox.createProperty(tBoxNs+DATEOFCREATION);
Calendar cal=Calendar.getInstance();
cal.setTime(cfm.getFechaCreacion());
lit=aBox.createTypedLiteral(cal);
Statement stment= aBox.createStatement(ind,prop,lit);
aBox.add(stment);
...
//pongo el tipo de autor. Por defecto alumno (learner)
//aado los roles
OntClass oc=aBox.createClass(tBoxNs+ROLE);
Individual
rolLearner=aBox.createIndividual(tBoxNs+LEARNERROLE,oc);
Individual
rolTutor=aBox.createIndividual(tBoxNs+TUTORROLE,oc);
Individual rolFacilitator
=aBox.createIndividual(tBoxNs+FACILITATORROLE,oc);
prop=aBox.createProperty(tBoxNs+AUTHORROLE);
if (//Tiene Rol de tutor de la comunidad){
ind.addProperty(prop,rolTutor);
}else{
if (//Tiene Rol de facilitador){
ind.addProperty(prop,rolFacilitator);
}else{
//supongo que en otro caso es alumno
ind.addProperty(prop,rolLearner);
}
}
...
Aunque hay muchos roles definidos en la TBox, la implementacin

del sistema de informacin del CFP limita los roles y slo tendremos
el de facilitador, el de tutor y el de alumno (roles utilizados para la
imparticin del curso).
6. Para cada comentario, de forma recursiva generamos su

informacin especfica por ser TreeItem. El detalle de la
recursividad se puede ver aqu, y destacamos la generacin de
propiedades de tipo xsd:boolean y la colocacin de relacin entre los
objetos TreeComments:
[Expr. 7.10]
...
if (//el mensaje tiene hijos){
for (//recorremos todos los hijos){
263
Individual ind=insertaMensaje(cfms[k]);
//le coloco su padre
prop=aBox.createProperty(tBoxNs+ISCHILDOF);
ind.addProperty(prop,indPadre);
//al padre le coloco su hijo. Redundante pero acelera
queries
prop=aBox.createProperty(tBoxNs+HASCHILD);
indPadre.addProperty(prop,ind);
//parte de recursividad. Insertamos sus hijos
insertaHijos(cfms[k],ind,--profundidadRestante);
}
}else{
//no tiene hijos, es un terminal del arbol LeafItem
Literal verdadero
=aBox.createTypedLiteral("true",XSDDatatype.XSDboolean);
prop=aBox.createDatatypeProperty(tBoxNs+ISLEAFITEM);
Statement
stm=aBox.createStatement(indPadre,prop,verdadero);
aBox.add(stm);
}
...
7. Por ltimo, pasamos nuestro modelo a un archivo OWL:
[Expr. 7.11]
File f=//definicin del fichero donde insertaremos el
//documento OWL
FileOutputStream os=new FileOutputStream(f);
RDFWriter writer=aBox.getWriter("RDF/XML-ABBREV");
writer.setProperty("xmlbase",aBoxURI);
writer.write(aBox,os,aBoxNs);
Y con esto concluimos los detalles de programacin de la extraccin de

informacin de los foros de una de las comunidades, para poder importarlos
en nuestro sistema.
7.3.5 Ejecucin de la importacin

Para emular el proceso de importacin de informacin a nuestro sistema,
realizamos un proceso que recorre todas las experiencias educativas de
nuestro caso de estudio y genere un fichero .owl para cada una, basndose
en la programacin del apartado anterior. Los ficheros OWL tendrn la
informacin de los foros y mensajes de cada curso al que pertenecen. El
proceso almacenar informacin sobre tiempos de generacin, nmero de
foros, threads y mensajes y profundidad.
264
El esquema de los equipos para realizar las pruebas es el de la Fig 7.16,

donde todo el sistema del extractor corre sobre un ordenador con sistema
operativo Windows XP Profesional, 2GHz y 1GB de RAM, a excepcin del
acceso a la base de datos del CFP, que se accede va Ethernet a un servidor
con Windows 2000 Server con 2GHz de RAM reservados para la base de
datos que corre en Microsoft SQL Server 2003.
Se realiza la emulacin en un periodo de tiempo en el que apenas hay acceso

a la base de datos (20:30 PM) y actividad en la red, ejecutando el programa
que genera cada uno de los 31 ficheros owl (uno por cada curso o
comunidad virtual). Este experimento se repite ocho veces para intentar
minimizar los errores de medida por causas puntuales. A cada una de las
repeticiones las denominaremos importacin 1 a importacin 8.
100 Mb
JDBC
BASE DE DATOS IMPORTADOR

Fig. 7.16. Esquema de montaje de equipos implicados en la importacin
A los ficheros generados se les ha chequeado la consistencia, clasificado y

comprobado que son OWL DL como se ha explicado para la TBox (Fig 7.9
y 7.10), dando resultados satisfactorios en todos los casos.
En el apartado siguiente ser vern algunos resultados del proceso que hemos
concluido, como tiempos en funcin del tamao y profundidad del foro, y la
ocupacin de disco de cada ontologa de un curso.
7.3.6 Resultados del proceso de importacin

En este apartado mostraremos resultados comparativos de distintas
importaciones, para poder extraer informacin sobre rendimientos en tiempo
de las importaciones, tamaos de archivos OWL generados, comparados
con los parmetros de cada uno de las importaciones (nmero de foros
importados, cantidad de mensajes y profundidad de las estructuras en rbol).
265
Los datos comparativos para cada una de las experiencias educativas de las
que se ha extrado informacin se muestran en la tabla 7.2.
ID N N Profundidad Tiempo Tamao Tamao

comunidad Foros Mensajes exportacin de comprimido
(ms) ontologa (KBytes)
.owl
(KBytes)
133 4 31 6 274 35 7
134 4 130 4 645 148 19
135 4 63 7 287 86 14
136 5 86 7 389 108 17
137 4 93 5 385 119 16
138 4 104 5 414 121 18
139 2 46 5 252 59 10
140 3 123 4 512 149 23
141 2 127 6 504 141 19
142 1 88 6 340 108 16
164 8 59 2 254 77 13
165 4 37 8 151 42 7
166 2 6 4 27 6 2
167 4 25 4 99 32 7
176 2 60 4 231 64 11
177 2 6 3 32 10 4
178 2 29 2 125 33 7
179 2 44 5 189 52 10
180 2 15 2 70 16 4
181 1 32 8 129 33 5
182 1 12 4 49 13 3
183 2 64 6 234 69 11
184 2 21 2 84 25 6
185 9 134 4 580 170 24
186 7 10 5 59 14 4
187 2 79 2 330 114 15
188 2 35 8 104 39 7
189 2 4 4 25 13 2
190 2 55 2 205 64 9
191 2 40 6 180 52 8
192 2 12 4 49 15 4
Tabla 7.2. Comparativa de las extracciones a .owl segn comunidades
266
En la tabla 7.2 se muestra los valores de resultado para cada una de las 31
experiencias educativas con las que se ha tratado. Como cada experiencia se
ha importado 8 veces, los valores temporales son la media de las 8
importaciones, para evitar errores puntuales.
En la tabla identificamos cada una de las comunidades por medio de su

identificador de comunidad. Una comunidad se puede equiparar en este caso
con una experiencia educativa, ya que contiene un conjunto de usuarios,
unos contenidos estticos, foros y tests. Se entiende como profundad del
foro, a nmero de niveles de anidacin de los mismo, de forma que un foro
debe tener como mnimo una profundidad de 1 (nadie contesta a ningn
mensaje de nadie). Para el clculo de los tiempos de extraccin (el tiempo
que dedica el importador en generar el archivo OWL correspondiente)
hemos eliminado el tiempo de arranque del extractor y mostramos la media
a lo largo de las ocho importaciones realizadas. Como podemos apreciar, en
las experiencias educativas existe una gran varianza respecto al nmero de
foros, mensajes y profundad de foros, pese a tratar los mismos contenidos
estticos.
El primer valor que calculamos en las extracciones es el tiempo necesario

para inicializar todas las clases que utilizamos para la importacin.
Medimos este tiempo por medio de marcas de tiempo en el cdigo desde el
inicio hasta que hemos generado en Jena el modelo, la ontologa y hemos
importado la TBox.
Descubrimos que este tiempo slo es apreciable para la transformacin en

OWL de la primera comunidad para cada importacin, siendo cero o menor
de 20 ms para el resto de comunidades. Atribuimos este fenmeno a:
El tiempo realmente apreciable es el de inicializacin de las

clases de Jena. Jena debe inicializar sus clases internas una vez y
mantenerlas cargadas en la mquina virtual de Java todo el tiempo
(por ejemplo, mediante clases Singletone). Muy probablemente
cuando importemos una ontologa en Jena (como en este caso con
nuestra TBox), no realice ninguna comprobacin sobre la misma
para chequear consistencias, sino que aada la sintaxis
correspondiente y nada ms.
267
El tiempo de acceso al sistema de ficheros debe ser ms importante

la primera vez que accedemos a un directorio desde una mquina
virtual que las siguientes veces.
La apertura de socket para la comunicacin JDBC con el servidor

de la base de datos es necesario slo la primera vez que accedemos a
la misma, ya que est implementado un sistema de pool de
conexiones a la base de datos que permite la reutilizacin de las
mismas conexiones). Aunque al principio no accedamos
directamente a la base de datos en la inicializacin, s que
instanciamos las clases Manager de la base de datos
(cfp.poseidon.mgr.*) que empiezan esta comunicacin.
Los valores obtenidos de inicializacin para las ocho importaciones nos dan
un valor medio de unos 8,5 segundos y con una desviacin tpica de medio
segundo, como comprobamos en la figura 7.17. Si consideramos que la
desviacin tpica calculada es la real, obtenemos que la media de tiempos de
inicializacin se encuentra entre 8,12 y 8,81 segundos con un 95% de
probabilidad. Comparando este valor temporal con los tiempos necesarios
para la extraccin de cada comunidad, vemos que los valores de los tiempos
de inicializacin son un orden de magnitud superior a los valores de los
tiempos de extraccin de una comunidad.
Fig. 7.17. Media del tiempo de inicializacin para las 8 importaciones
268
Otro valor que sacamos es la relacin entre el tiempo de creacin de los

archivos owl (quitada la inicializacin) y la cantidad de mensajes de la
comunidad. Se calcula las rectas de regresin para cada uno de los 8
experimentos (Fig. 7.18), calculando al final la curva de regresin de las
medias de tiempos de los 8 experimentos (Fig. 7.19), para el que obtenemos
una relacin lineal. Por tanto podemos concluir que existe una relacin
lineal entre tiempos y nmero de mensajes a extraer.
269
Fig. 7. 18. Rectas de regresin de las ocho importaciones
Fig 7.19. Recta de regresin de las medias
En la figura 7.19 podemos observar que si aplicamos la recta de regresin a

la media de cada uno de los experimentos obtenemos una relacin casi
lineal, con un tiempo de 4,1 milisegundos por mensaje enviado al foro. A
partir de esto podemos hacernos una idea del tiempo que le puede costar a
un agente validar cada ABox que obtiene.
Realizamos un estudio tambin sobre la relacin entre el nmero de

mensajes y el tamao del archivo owl, tanto su tamao directo como
comprimido. La compresin se realiza en formato .zip. Con este estudio
pretendemos saber cmo dimensionar el almacenamiento, tanto para los
servidores de contenidos semnticos como para los propios agentes.
270
Concluimos en abos casos que el crecimiento del tamao es lineal con la

cantidad de mensajes en la comunidad, siendo un poco menos claro para los
archivos comprimidos (r=0,98) que en los no comprimidos, y teniendo los
archivos comprimidos un tamao inicial (independiente de los mensajes)
mayor que el del archivo no comprimido. En la figura 7.20 podemos
apreciar que el tamao inicial de los archivos comprimidos es unos 2Kbytes,
frente a los 500 bytes del archivo no comprimido, pero ya a partir de 2
mensajes de la extraccin se ocupa menos espacio de disco con los archivos
comprimidos, por lo que la compresin ser recomendable en todo caso. En
este caso no se hace la media para cada importacin, ya que en cada
importacin se obtienen los mismos archivos.
Fig. 7.20. Tamaos de los archivos sin comprimir y comprimidos
La mejora que introduce la compresin es reducir a un 13% el tamao

medio de ocupacin por mensaje (de 1,2 KB a 0,16 KB), aunque de todas
formas los tamaos de los archivos OWL son comparables al tamao de
cualquier imagen (normalmente .gif o .jpg) del contenido esttico del curso
(el mayor tamao es de 170KB). Esto nos hace concluir que almacenar el
archivo OWL no ha de ser ningn problema a nivel almacenamiento en los
propios repositorios de contenidos.
7.4 Sistema de bsquedas e inferencias

En este apartado explicaremos el prototipo realizado para la realizacin de
inferencias y bsquedas sobre la informacin OWL DL que hemos extrado
de nuestros foros reales. Este apartado pretende comprobar el
comportamiento de los posibles agentes de bsqueda de nuestra
arquitectura. Dichos agentes obtendrn conocimientos de archivos .owl que
les vaya interesando y sobre stos conocimientos realizar las inferencias.
En la figura 7.21 podemos ver la parte de nuestra arquitectura que vamos a
271
validar, es decir, el comportamiento del agente que obtiene informacin

semntica, realiza bsquedas inteligentes y presenta resultados al usuario.
BUSCAR (K1, TBox)
DHT SEMANTICA
AGENTE V = OWL URL
OWL
OWL URL
PUBLICADOR
SEMNTICOS
OWL
ALMACEN INFORMACION
SEMNTICA
.OWL
LO-A LO-B LO-C

Fig. 7.21. Parte de la arquitectura simulada en este apartado
Para realizar este prototipo se plante la posibilidad de utilizar alguna API

que permita inferencias (como puede ser Jena 2 [DICK04] o la API de
Protg) o utilizar alguna de las herramientas de autor que permiten
inferencias como Protg o SWOOP.
Como la arquitectura que queremos plantear se basa en un agente inteligente

que presenta al usuario un conjunto de posibilidades de bsqueda para que
sea el usuario quien las formule, consideramos que una herramienta como
Protg ser la ms adecuada. Protg permite realizar inferencias y
encontrar las instancias que cumplen unas determinadas propiedades.
272
Contiene, adems un plug-in de RDQL para realizar queries a nivel de RDF

, que permitir realizar bsquedas mixtas entre localizacin de palabras en
los recursos e inferencias sobre los mismos (bsquedas RDF y OWL).
Tambin contiene una ampliacin denominada Queries que permite hacer
bsquedas directas en nuestra base de conocimiento.
Por tanto el esquema sera el mismo que para el chequeo de ontologas

(figura 7.9), pero eligiendo un nico razonador. En este punto tenemos que
decidir cul de los razonadores ms utilizados para OWL DL (FaCT++,
Racer, Pellet) es al ms adecuado para las ontologas que utilizamos y el
esquema propuesto. Por esta razn se describirn las tres posibilidades y se
har una pequea prueba para evaluar rendimientos y comparar los
razonadores. Por tanto a continuacin describiremos los tres razonadores,
realizaremos una comparacin de uso, caractersticas y rendimientos y
elegiremos el ms adecuado para nuestros propsitos.
7.4.1 FaCT++ 1.1.3

FaCT++ [WWW71], desarrollado por la Universidad de Manchester, es la
continuacin del razonador opensource para TBoxes FaCT (Fast
Classification of Terminologies), siendo la versin antigua desarrollada en
Lisp y la versin actual desarrollada en C++ para acelerar los algoritmos.
La nueva versin permite ya razonar con ABoxes y en las ltimas versiones

ha mejorado bastante su interfaz con DIG. FaCT++ est optimizado para la
lgica de OWL DL. Los algoritmos utilizados son optimizaciones del
algoritmo Tableaux.
Su instalacin sobre windows conlleva cierta dificultad al tener la necesidad

de instalar la plataforma .NET 2.0, y no se ha encontrado informacin
alguna sobre su instalacin, manejo y mensajes de error mostrados por el
razonador. Su desarrollo se lleva de forma particular entre dos personas (Ian
Horrocks y Dmitry Tsarkov [TSA03],[TSA04],[GAR06])y no tiene el
apoyo de ninguna comunidad de desarrolladores y beta-testers asociado, por
lo que se encuentra an en una fase algo inestable.
Aunque no disponga de informacin de uso y ayuda, al menos el servidor

HTTP de DIG muestra por su salida estndar bastante informacin relativa a
las acciones que realiza y errores que ocurren. Su interfaz DIG permite
ejecutarlo como servidor HTTP. En la Fig. 7.22 podemos observar un
ejemplo de utilizacin de FaCT con Protg.
273
Fig. 7.22. Uso de FaCT++ con Protg
7.4.2 RACER 1.9

Racer (Reasoner for Aboxes and Concept Expressions Renamed)
[WWW13] fue uno de los primeros razonadores para ABoxes que apareci
en el mercado (hay versiones desde el ao 2002). Se desarroll por las
universidades alemanas de Hamburgo y actualmente es software propietario
y de pago, aunque permite una descarga de prueba de tres meses.
Racer 1.9 soporta OWL DL excepto para los nominales (clases definidas por
una enumeracin de sus miembros, que implementa como definiciones
parciales) y para tipos de datos no estndar (fuera de xsd:X). Al contrario
que las primeras versiones, por defecto no asume UNA (Unique Name
Assumption), para ser compatible con OWL. Se basa en el algoritmo
Tableaux con optimizaciones y cacheos de inferencias obtenidas.
Racer es un razonador con ms posibilidades que un simple razonador

OWL, ya que incluye un cliente para hacer queries en OWL-QL
(RacerPorter), su propio lenguaje de queries (nRQL, new Racerpro Query
Language) e incluye una herramienta de cliente exclusiva (RICE, Racer
Interactive Client Environment), y una API en Java para poder interactuar
con l directamente (JRacer).
7.4.3 Pellet 1.3

Este razonador [WWW59] (actualmente versin 1.3-beta 2) es un razonador
opensource desarrollado por Mindswap. Pellet es un razonador exclusivo
274
para OWL DL e implementado en java, que implementa el interface DIG y

adems RDQL para queries sobre la informacin en RDF. Adems, dispone
de una API para poder ser utilizado directamente desde Java.
Como los otros dos sistemas, se basa en el algoritmo Tableaux, como se

indica en [PAN05]. De todos los razonadores probados, la implementacin
de DIG es la que presenta errores ms aclaratorios para la correccin de
ontologas y adems es el razonador que ms chequeos hace al principio, el
que te permite corregir errores en la ontologa directamente. Adems, al
recibir una ontologa realiza optimizaciones internas, de forma que los
siguientes queries sean ms rpidos. Es el nico que se presenta tambin
como una web donde se puede enviar el archivo .owl para validarlo, como
vimos en la figura 7.11.
7.4.4 Seleccin del razonador. Comparativa de uso

Para seleccionar el razonador primero compararemos sus caractersticas
generales y por ltimo realizaremos unas mediciones de rendimiento de los
mismos.
Existen varias comparativas entre razonadores para OWL [PAN05],

[WWW60], [GAR06], [HAA05], [RUT05] aunque las conclusiones finales
son que no hay un razonador mejor que los dems, sino que depende de las
ontologas que usemos en concreto para ver los rendimientos y de quin
haga dicha comparativa. Lo que queda constatado en la mayora de
comparativas es que Pellet da una respuesta muy aceptable en todas las
comparativas.
7.4.4.1 Comparativa de caractersticas generales

Como podemos ver en la tabla 7.3 resumen de la comparativa, todos
implementan el interfaz DIG, por lo que podremos utilizar dicho interfaz a
la hora de implementar un prototipo que pueda ir cambiando de razonador.
Caracterstica FaCT++ Racer 1.9 Pellet 1.3

Evaluacin objetiva
Multiplataforma NO NO SI
Cdigo abierto SI NO SI
Freeware SI NO (3 meses de SI
prueba)
Implementacin SI SI SI
DIG
API para utilizar NO SI SI
275
Orientacin a Total Media Total

OWL
Evaluacin subjetiva
Facilidad de Medio (.NET Alto Alto
instalacin 2.0)
Informacin sobre Medio Bajo Alto
errores en
inferencias
Comunidad de NO NO SI
desarrolladores
implicados
Tabla 7.3. Comparativa de los razonadores
En la tabla 7.3 apreciamos que FaCT y Pellet son soluciones opensource y

gratuitas, mientras Racer es una versin de pago (aunque se puede utilizar
de forma indefinida con el interfaz DIG, por lo que se considerar como
posibilidad factible para implementar el prototipo). Otra caracterstica
importante, para la generacin de agentes inteligentes que tengan su propio
razonador integrado, es la existencia de una API para poder atacar al
razonador directamente. En este caso tanto Racer como Pellet ofrecen una
API en java para realizar dicha integracin. De todas formas, consideramos
que la arquitectura que ataca al razonar por medio de HTTP por medio de
DIG es una arquitectura similar a la de servicios Web que puede ser muy
interesante para futuras implementaciones.
En la comparacin subjetiva, vemos que FaCT, pese a ser opensource, no

cuenta con mucha informacin de ayuda, ni comunidad grande de soporte,
adems de ofrecer poca informacin al usuario en caso de error (aunque un
poco ms de la que ofrece Racer en su interfaz DIG). Slo Pellet cuenta con
el apoyo de una comunidad de desarrolladores y beta testers que permite
acelerar la madurez del producto.
Tras realizar esta comparativa general, veremos en el siguiente apartado una

comparativa objetiva sobre rendimientos, haciendo que los tres razonadores
trabajen con la ontologa especificada en esta Tesis y con las instancias
particulares provenientes de la importacin de datos reales realizada.
7.4.4.2 comparativa de rendimientos

Para evaluar el rendimiento, utilizaremos el mismo esquema de trabajo que
para el chequeo de las ontologas (ver Fig. 7.9), donde atacamos a los
razonadores (en este caso tres, FaCT, Racer y Pellet) por medio de DIG
276
sobre HTTP, por lo que tendremos una nica instancia de Protg (a modo
de interfaz de usuario) que ir atacando a los tres razonadores (cada uno
trabajando sobre un puerto) y realizndoles varias pruebas de rendimiento,
midiendo los tiempos de respuesta como variable de rendimiento.
Los seis tipos de prueba de rendimiento que vamos a utilizar son:
Chequeo de consistencia de nuestra TBox. Es decir, comprobar

que no hay clases inconsistentes (que nunca podrn tener instancias).
Contiene 25 clases, 23 propiedades y 6 instancias (los Roles).
Chequeo de consistencia de una ABox importada. Chequea la

consistencia de nuestra TBox ampliada con una de nuestras ABoxes.
En este caso se cogern los datos del foro ID=134 (ver tabla 7.2),
con 4 foros, 130 mensajes en una profundidad de hasta 4 niveles.
Clasificacin de nuestra TBox. Esto revisa las clases una por una
para ver si existe algn tipo de herencia implcita en la declaracin,
de forma que podamos saber todas las clases de las que es
especializacin la clase inicial.
Clasificacin de la ABox de la comunidad 134, como se comenta

en el punto anterior.
Clculo de tipos inferidos en la ABox. Esta peticin consiste en

solicitar al razonador que infiera a qu clases pertenece cada
instancia, aunque no lo hayamos indicado explcitamente en el
documento OWL.
Simulacin de una inferencia. En este caso, buscaremos todos los

recursos que sean descendientes del comentario ID=1129. Para hacer
esto definimos una clase descendiente de la clase TreeComment, que
se caracteriza porque sus instancia son todas las que se relacin por
medio de la propiedad isDescendentOf con el comentario particular
1129 (TreeCommentID_1129).:
[Expr. 7.12]
Descendientes _ de _ 1129 TreeComment
Descendientes _ de _ 1129 isDescendentOf TreeCommentID _ 1129
277
Se ha elegido esta inferencia porque su contestacin necesita un

agente que no busque nicamente por palabras o conjuntos de
caracteres, sino que permita razonamientos y por tanto podamos
definirle una propiedad isChildOf que sea subpropiedad de otra
transitiva denominada isDescendentOf, y buscar por algn valor de
esa propiedad transitiva.
Para implementar las bsquedas inteligentes en Protg, se opta por

definir las propiedades que buscamos en nuestras instancias como
una clase a la que no le colocamos ninguna instancia directamente.
Luego pedimos al razonador que realice el clculo de tipos inferidos,
accin que comprueba si las instancias que tenemos se pueden
colocar como miembros de cualquier clase de nuestra ontologa que
no est explcitamente en nuestra ontologa inicial, por lo que
contestar a nuestra inferencia rellenando la clase con las instancias
que lo cumplan.
Se comprueba manualmente que en este caso hay dos instancias de la

clase TreeComment que son descendientes de la instancia con
identificador de comentario 1129, que son las instancias con
indentificadores de comentario 1278 y el 1296 (Ver Fig 7. 23).
Fig. 7. 23. Resultados de la inferencia realizada con Protg y Pellet
Por ejemplo, en la figura 7.23 vemos el resultado en Protg tras definir la

clase Descendientes_de_1129 como se indica en la expresin 7.12 y
278
solicitar la inferencia de clases al razonador conectado va DIG (en este caso

Pellet). Vemos que ha inferido que las instancias TreeCommentID_1278 y
TreeCommentID_1296 pertenecen a esa clase, por tanto son descendientes
del comentario 1129. Tambin apreciamos que no slo ha inferido esta
clase, sino que ha realizado todas las inferencias de pertenencia a clases de
su base de conocimiento. Por ejemplo, pese a no indicar en nuestros
archivos OWL ninguna instancia de la clase LeafItem, vemos que existen 84
instancias que pertenecen a esa clase.
7.4.4.3 Resultados de la comparacin de rendimientos

Para comparar los rendimientos de los motores de inferencias, en una
primera fase se hicieron las pruebas de forma que, por cada razonador,
repetamos 16 veces la misma prueba sin resetear el sistema cada vez (por
ejemplo, clasificamos la TBox 16 veces seguidas con Racer).
En la figura 7.24 podemos ver comparados los rendimientos de los tres

razonadores, en los que se ve una gran diferencia entre la primera ejecucin
del primer tipo de prueba y las siguientes 15 repeticiones del primer tipo de
prueba. En cada grfica se agrupan el mismo tipo de prueba, para los tres
razonadores estudiados.
279
Fig.7.24. Diferencia entre el primer experimento y siguientes en tres tipos

de pruebas
En los grficos de la figura 7.24 se comprueba que existe una gran

diferencia entre la primera vez que se realiza el experimento y las siguientes
veces. Esto es debido a que los razonadores, para mejorar el rendimiento,
cachean los resultados de los queries que les hacemos, como se indica en
[GAR06], y adems si no cambiamos la ontologa cachean tambin las
inferencias realizadas la primera vez que le pedimos al razonador que lo
haga. Por tanto concluimos que para evaluar el rendimiento no podemos
repetir la misma prueba sobre el mismo razonador sin haber reseteado antes
el razonador, ya que al cachear los resultados falsea el tiempo de clculo de
los mismos.
Esto nos hace pasar a la segunda parte de las pruebas, donde nos interesa
medir los valores de los tres razonadores de la forma ms aleatoria posible y
buscando que el razonador resetee su memoria entre experimento y
experimento, para simular el rendimiento de nuestros agentes inteligentes
cada vez que hay una ontologa nueva o se aaden conocimientos a la
misma.
280
Para cada tipo de prueba de rendimiento, para evitar las fluctuaciones

aleatorias que puedan ser debidas a otras causas, realizaremos ocho pruebas
iguales por cada razonador, atacando a los razonadores de forma alternada
para que las posibles fluctuaciones aleatorias afecten por igual a los
resultados de los tres razonadores. En las grficas de las figuras 7.25 y 7 .26
veremos los resultados obtenidos. En cada grfica representaremos las ocho
repeticiones (con reseteo entre cada repeticin) de un tipo de prueba para los
tres razonadores (24 experimentos por grfica), marcando con raya
discontinua la media de cada razonador.
281
Fig. 7. 25. Comparativas de rendimiento con reseteo entre cada prueba
En la figura 7.25 tenemos las grficas de los 4 primeros tipos de pruebas, es

decir, los chequeos y las clasificaciones de la TBox y la ABox. Esta parte se
puede considerar el rendimiento de un agente inteligente a la hora de
ampliar su base de conocimiento con nuevas ontologas (TBox) o con
instancias de las ontologas que ya tiene (ABox). Pellet es el razonador que
de momento ofrece mejor resultado para todas las pruebas.
282
Fig. 7.26. Comparativas de rendimientos al inferir los tipos
En las grficas de la figura 7.26 se indican los rendimientos a la hora de

inferir tipos y resolver la inferencia del ltimo tipo de prueba definido, que
asimilamos con los rendimientos de razonamiento del agente inteligente que
est utilizando ese motor de inferencia. Como podemos ver en las grficas,
la media ms baja en todos los casos es la que ofrece Pellet, siendo tambin
el razonador con las varianzas ms pequeas comparando con el resto de
razonadores. En la tabla 7.4 podemos ver los valores numricos de las
pruebas realizadas.
valor FaCT ++ Racer 1.9 Pellet 1.3

(ms)
1) Consistencia media 310 316 173
TBox varianza 249 145 9,9
2) Consistencia media 2765 1576 619
ABox varianza 532 82 47
3) media 434 391 289
Clasificacin varianza 295 143 38
TBox
4) media 2488 1707 588
Clasificacin varianza 515 224 158
ABox
5) Tipos media 2450 2334 2134
Inferidos ABox varianza 501 504 49
6) Simulacin media 2908 6681 2277
de inferencia varianza 527 1898 43
Tabla 7.4. Comparativa de rendimientos de los razonadores
283
En la tabla 7.4 corroboramos lo que se haba visto en las figura 7.25 y 7.26,
que los mejores rendimientos en las seis pruebas los ofrece el razonador
Pellet, ofreciendo tambin los ms estables, ya que la varianza es menor.
Esto no tiene por qu significar que un razonador es mejor que otro en todos
los casos, pero s que podemos concluir que, para el tipo de uso propuesto
(con Protg y DIG) , para TBoxes y ABoxes como los que utilizamos.
Pellet es quien da mejores resultados y adems el que ofrece valores ms
estables. Estos resultados de rendimiento vienen a sumarse a la comparativa
general de razonadores de la tabla 7.3, donde el mejor valorado es tambin
Pellet.
Se puede apreciar que Racer es el siguiente en mejores resultados, menos en

la simulacin de la inferencia (que es realmente para lo que queremos el
razonador en el prototipo). Adems, FaCT es el que ofrece valores ms
variados (mayor varianza calculada) excepto en la simulacin de la
inferencia.
Por estas razones utilizaremos Pellet como razonador en nuestro prototipo,

al ser el mejor evaluado en la mayora de los puntos estudiados. Es muy
probable que la seleccin de un razonador u otro pueda ir variando segn las
versiones de los mismos se van desarrollando, por lo que nuestra
recomendacin de Pellet es para este prototipo y con las ltimas versiones
de razonadores que hemos podido obtener.
7.4.5 Descripcin del sistema de bsquedas

Para comprobar el sistema de bsquedas del agente inteligente, partiremos
de las siguientes premisas:
Supondremos que el agente de bsqueda ha actualizado su base de

conocimiento como se especifica en el captulo de arquitectura
propuesta. En nuestro prototipo simularemos dicha adquisicin de
informacin por medio de los imports de Protg.
Una vez conseguida la informacin necesaria, mostraremos cmo

poder hacer bsquedas RDF (que no OWL) para buscar por medio
de substrings.
Realizada las bsquedas por substrings, mostraremos cmo realizar

bsquedas en OWL, que necesiten del razonador escogido. Las
inferencias se realizarn de igual forma que se han realizado en el
284
apartado de comparacin de rendimientos. De esta forma

realizaremos bsquedas mixtas, en las que se realizarn inferencias y
se poblarn clases con bsquedas de palabras clave en RDF.
A continuacin detallaremos cada uno de los tres pasos para esta validacin.
7.4.6 Carga de conocimientos en el agente

Como ya dijimos anteriormente, utilizaremos Protg como base para la
simulacin. Generaremos primero una ontologa vaca, dentro del espacio de
nombres que asignamos a nuestro agente:
[Expr. 7.13]
http://dcom.upv.es/owl/rorollo/agenteKB#
Luego realizaremos importaciones los documentos OWL que contienen la

TBox y de las distintas ABox obtenidas en el proceso de importacin de
datos reales. Por ejemplo, supondremos un agente que ha obtenidos los
datos de foros de cuatro comunidades (id=134, 140, 145 y 185).
Para realizar esto en Protg, utilizamos la pestaa Metadata y aadimos las

importaciones necesarias, indicando no slo la URI importada, sino la
ubicacin fsica de esa URI en fichero, ya que como comentamos la URI es
un identificador nico y no tiene por qu ser un localizador uniforme URL
(ver Fig. 7.27).
Fig. 7.27. Importaciones de ontologas de las comunidades
En la figura 7.27 vemos como importamos las ABox de los foros de

comunidades que vamos a utilizar en la prueba. No indicamos la TBox, ya
que cada una de las ABox indica que importa la TBox, por lo que el sistema
buscar esa TBox directamente. S que es necesario indicar en otro lugar de
285
Protg la ubicacin fsica donde puede encontrar informacin relativa a la

URI de la TBox, ya que tampoco es una URL disponible.
Les daremos un espacio de nombres distinto a cada una de las

importaciones, de modo que podamos visualmente saber de qu comunidad
se ha importado cada cosa. De esta forma nuestro agente dispone ahora de
una base de conocimiento con ms de 500 mensajes procedentes de 18 foros
distintos de 4 imparticiones del mismo curso (ver Fig. 7.28).
Fig. 7.28. Objetos en la base de conocimiento de nuestro agente
En la figura 7.28 podemos ver las instancias que ha cargado el agente, de

forma que, por ejemplo, tiene 514 comentarios en su base de conocimiento.
Con Pellet realizamos un chequeo de consistencia que dura 4 segundos y

una inferencia de tipos para clasificar las instancias que nos cuesta 30
segundos de media. Vemos que los tiempos son relativamente altos y esto es
debido a que la complejidad de los algoritmos utilizados (Tableaux) tiene un
crecimiento exponencial con el nmero de elementos incluidos en el
razonamiento.
Una vez el agente ha adquirido la informacin necesaria, realizar

bsquedas en su base de conocimiento. En este caso sern bsquedas mixtas
RDF/OWL, que permite realizar inferencias y tambin realizar bsquedas
por palabras clave, ya que lo que pretendemos es mejorar y ampliar las
bsquedas por palabras clave, no sustituirlas completamente por bsquedas
OWL.
286
7.4.7 Bsquedas por palabras clave

OWL no permite realizar bsquedas dentro de los valores de las funciones
de tipos de datos (como puede ser buscar substrings dentro de una valor
xsd:string), por lo que tenemos que recurrir a una capa ms profunda, hasta
RDF para poder realizar dichas bsquedas.
Existen mltiples lenguajes para indicar bsquedas en un conjunto de grafos

RDF [WWW61]. Los podemos dividir en 3 grupos:
Queries basados en sintaxis SQL, como RDQ, RDQL, SeRQL y

SPARQL.
Queries que utilizan el propio RDF o XML para definir las

preguntas y las respuestas. En este grupo tenemos N3QL (que usa
RDF pero en su versin abreviada Notation 3) y RDFQ.
Queries en otros lenguajes o especficos de las aplicaciones, como

el sistema de Queries de Protg (Query Tab) y Versa.
W3C est adoptando SPARQL como candidato a recomendacin desde

Abril de 2006 [WWW62], y Protg ha aadido un plug-in de RDQL en su
ltima versin (3.2 beta).
Sin embargo, nosotros vamos a utilizar una versin ms visual de los

queries que es la ampliacin Query Tab que proporciona Protg. Query
Tab permite realizar bsquedas de individuos que cumplen un cierto criterio
sencillo. Adems, la versin 3.2 beta de Protg es, a fecha de la realizacin
de este experimento, muy inestable y tiene graves problemas de
transformacin a DIG 1.1.
Como ejemplo, el agente buscar en su base de conocimiento los

comentarios que contengan el texto extintor en su contenido (Ver Fig.
7.29). Nos devuelve los comentarios con identificadores 676, 817, 2695 y
2699.
287
Fig. 7. 29. Bsqueda por substrings
En este punto, si fuera una bsqueda real, el usuario podra comprobar los
textos de los comentarios y seleccionar los que ms le convenga, o
directamente solicitar al agente que le busque los nombre de los Threads
distintos en los que se habla de extintores, o las comunidades en las que se
ha hablado sobre extintores. Para resolver estas ltimas consultas se
necesitan razonadores, y es lo que se mostrar en el apartado siguiente.
7.4.8 Inferencias en OWL

Aunque hay algunas propuestas de lenguajes para realizar queries sobre
OWL (como OWL-QL) y algunas extensiones para realizar inferencias
sobre bases de conocimiento (como por ejemplo, nRQL para Racer), no
estn suficientemente desarrolladas o lo estn slo para algn tipo de
razonador (nRQL). Por esta razn haremos las inferencias como hemos
comentado anteriormente, es decir, por medio de la generacin de clases
definidas con nuestros parmetros de bsqueda y realizaremos una clculo
de tipos inferidos nos incluir en la clase todos los individuos que cumplan
las restricciones.
Siguiendo el ejemplo anterior, queremos saber los primeros elementos

(instancia de la clase RootItem) de los threads donde se habla de extintores.
Para realizar esto hacemos lo siguiente:
1. Generar una clase definida llamada Comentarios_sobre_extintores

donde colocaremos las clases que nos ha devuelto las bsquedas por
palabra clave. Esta accin se realizar manualmente, mientras que en
288
el caso de uso de agentes inteligentes tendra que ser el propio agente

el que definiera estas clases enumeradas.
[Expr. 7.14]
Comentario_sobre_extintores {
c134 : TreeCommentID_817
c185 : TreeCommentID_2699}
En la expresin 7.14 vemos la definicin de la clase enumerada,

donde c134 y c185 son los alias de los espacios de nombres
correspondientes a la comunidades 134 y 185.
2. Mirar cules de los elementos de esta nueva clase son ya instancias

de la clase RootItem. En nuestro ejemplo son los objetos de la clase
TreeComment con ids 817 y 676.
3. Inferir qu instancias de la clase RootItem tienen algn elemento de

esta nueva clase Comentario_sobre_extintores como descendiente:
[Expr. 7.15]
RootItem_relacionado_extintores
RootItem hasDescendent.Comentario_sobre_extintores
En la expresin 7.15 vemos que hemos definido la clase que

poblaremos con los resultados al realizar el clculo de tipos
inferidos.
El tiempo para inferir los individuos que pertenecen a esta nueva clase est
sobre los 4 segundos ( tiempo total 4,047 segundos, ver Fig. 7.30).
289
Fig. 7.30. Inferencia de los individuos que pertenecen a la nueva clase.
Como vemos en la figura 7.30, el motor de inferencia ha descubierto que en

nuestro ejemplo, tanto el objeto TreeComment id=2695 como el objeto
TreeComment con id=2699 estn en el mismo thread cuyo elemento
RootItem es la instancia de la clase TreeComment con id=2666.
7.5 Conclusiones de la validacin del sistema

Como podemos ver el prototipo ha sido capaz de asistir al usuario en la
bsqueda de comunidades (y por tanto, cursos) que estn relacionados con
una temtica determinada. Tambin se podran realizar otros tipos de
inferencia, segn se vaya ampliando la TBox con nuevos conceptos y
definiciones relacionadas con los foros. Por tanto la principal conclusin de
este captulo radica en que la ontologa especificada en esta Tesis es vlida y
til para la realizacin de bsquedas inteligentes.
Tambin validamos mediante esta prueba de concepto partes de la

arquitectura propuesta en el captulo 5, ya que hemos validado las partes
relacionadas con OWL de la misma: la extraccin de informacin semntica
de experiencias educativa existentes y la realizacin de bsquedas
inteligentes por parte de agentes. Se ha demostrado la posibilidad de extraer
informacin semntica de los cursos (prototipo del extractor de informacin
semntica), as como el uso de los agentes de la informacin semntica. La
validacin de la DHT semntica no es directa, sino que se basa en la
validacin de la DHT bsica, bastante validada por sistemas como eMule,
siendo lo novedoso la nueva utilidad que se le da y las claves de bsqueda
que se utilizan. Por tanto, dado que las diferencias son principalmente el
290
aadido de la marca de ABox/TBox en la DHT, podemos considerar esta

marca como parte de la clave utilizada por la DHT bsica, por lo que
proponemos sea un string (ABox o TBox) aadido al nombre de recurso
a buscar, de forma que al aplicar la funcin hash al nombre del recurso para
obtener la clave, nos ubique la informacin de la TBox y la ABox de forma
independiente (ver Fig. 7.31).
DHT
SEMNTICA DHT
BUSCAR (K1, TBox) BUSCAR (Tbox+ K1)
INSERTAR
(Tbox+K1,V)
Fig. 7.31. Transformacin de funciones de la DHT Semntica a DHT
Podemos observar en la figura 7.31 como se puede transformar una peticin

a la DHT Semntica por una peticin a la DHT normal, por lo que slo
tenemos que utilizar la DHT actual y aadirle un interfaz que traduzca entre
peticiones de la DHT Semntica a peticiones en DHT normal.
La parte de la arquitectura relativa a la distribucin de contenidos

educativos una vez localizados no se desarrollar ms a fondo en la Tesis,
ya que en este caso el inters se centra en las bsquedas inteligentes de
recursos ms que en el acceso a los mismos. De todas formas dicha
distribucin se propone que se base en los protocolos ya testeados por
millones de usuarios: HTTP y BitTorrent.
Otra conclusin a la que llegamos es que tanto las herramientas como los
estndares para OWL estn an en fase inicial de desarrollo. Si ahora se est
empezando a estandarizar los queries sobre RDF (con SPARQL), podemos
imaginarnos que queda an tiempo para la estandarizacin de la siguiente
capa OWL. Hasta el interfaz DIG 1.1 tiene indefiniciones que nos limitan la
expresividad en OWL [RUT05]. Por otro lado, aunque Protg es una
herramienta muy testeada, incluso las ltimas versiones (3.2 beta) tienen
gran cantidad de errores y excepciones inesperadas. Respecto a los
291
razonadores, hemos tenido que trabajar con versiones beta debido al

continuo desarrollo de los mismos. Incluso muchos no cubren OWL DL
completamente (como es el caso de Racer).
Otra necesidad que detectamos para que las bsquedas semnticas sean ms
tiles, es la necesidad de filtrar elementos por capas inferiores a OWL. Es
por esto, que en la validacin de nuestro agente ya hemos introducido el
concepto de bsquedas mixtas, en las que se puede buscar por palabras
clave. Este proceso es similar a lo implementado en SPARQL para RDF,
que permite definir filtros con queries de XQuery (por ejemplo, para buscar
por palabras clave). De este modo debera desarrollarse un lenguaje de
Queries en OWL que permita realizar filtros de capas inferiores, de forma
que hiciera clases annimas con los resultados obtenidos por ese filtrado,
del mismo modo que hemos hecho nosotros en nuestro prototipo con los
individuos con la palabraextintor en parte de su campo texto. Por tanto el
modelo de filtrado mixto presentado en esta Tesis podra ser el ejemplo a
seguir para la definicin del lenguaje de consulta a OWL, as como la
prueba realizada en este captulo sera un ejemplo de funcionamiento por
parte de los razonadores para resolver estas bsquedas mixtas.
Es importante destacar que OWL-DL tambin tiene la limitacin a la hora

de poder definir reglas, como por ejemplo propiedades que sean el
encadenamiento de otras propiedades. Esto nos permitira, por ejemplo,
definir una propiedad que relacione un objeto TreeComment cualquiera con
la instancia de la clase LearningActivity en la que est incrustado el foro al
que pertenece:
[Expr. 7.16]
X TreeComment , Y RootItem, Z ForumThread
hasDescendent (Y , X ) isFirstItemOf (Y , Z ) belongToThread ( X , Z )
K Forum, L SCORMLearningActivity
belongToThread ( X , Z ) isForumThreadOf ( Z , K ) belongToForum( X , K )
belongToForum( X , K ) relatedTo( K , L) belongToSCORMLearningActivity ( X , L)
Expresiones como la 7.16 nos permitira encadenar bsquedas ms

complejas y por tanto con menos interaccin por parte del usuario. Hemos
de indicar que existe el lenguaje SWRL, que ampla OWL con reglas.
SWRL est soportado tambin por Protg pero no por la mayora de los
razonadores. La razn radica en que el uso de reglas implica algoritmos
292
distintos a los basado en Tableaux para probar teoremas. En estos casos es

ms acertado el uso de encadenamientos hacia delante (forward chaining o
data driven) y hacia detrs (backward chaining o goal driven).
Tambin hace falta la optimizacin de los algoritmos de los razonadores, ya

que el crecimiento de la ontologa genera un crecimiento exponencial de los
recursos necesarios. Por ejemplo, la inferencia de tipos de la ontologa con
una comunidad (id=134) con 130 mensajes costaba de media 2,3 segundos,
mientras que la clasificacin de una otologa que importe 4 comunidades (
514 mensajes) nos da unos valores de rendimiento de unos 40 segundos para
inferir los tipos.
La ontologa propuesta abre las puertas para que en un futuro puedan

ampliarse las aplicaciones de la misma. Por ejemplo, se podran incluir
conceptos que permitieran una clasificacin basada en UDC [WWW64] o
LCC [WWW65], lo que permitira que cada foro o curso indicara sobre qu
temticas est trabajando, y de esta forma acotar nuestra bsqueda a las
temticas en que estamos interesados. Es este caso se podran realizar dichas
clasificaciones en una implementacin OWL de la especificacin del Simple
Knowledge Organization System (SKOS) [MIL05], [DEH06], ya que es una
especificacin basada en RDF. De todas formas, al trabajar con suposicin
OWA, nuestra ontologa es susceptible de ser ampliada en el futuro, siendo
esta una de la mayores ventajas del uso de OWL.
293
294
Captulo 8. Conclusiones y lneas de trabajo futuras
Captulo 8: Conclusiones y
lneas de trabajo
futuras
8.1 Introduccin
En todo trabajo o estudio se necesita una contextualizacin donde se
indiquen los fundamentos tericos, las condiciones de trabajo y el estado del
arte. Tambin es necesario un conjunto de suposiciones y experimentos o
pruebas de concepto que permitan validar las suposiciones. Adems, todo
trabajo se encuentra incompleto sin conclusiones. Las conclusiones son una
de las partes esenciales del mismo, ya que permiten explicitar el
conocimiento generado y sirven de punto de revisin. Ser de este alto en el
camino de donde partirn futuros trabajos. En este captulo se indican a
modo de resumen las conclusiones que han ido apareciendo en los distintos
captulos.
295
Se pretende que la Tesis Doctoral, que cierra un ciclo, abra otro ciclo, de
modo que se convierta en un principo para futuras investigaciones y
desarrollos, ya sea de forma individual o por medio de una colaboracin
entre miembros de la comunidad cientfica, que interacten entre s por
medio de reuniones, artculos compartidos o participacin en foros
comunes. Por esta razn dedicaremos un apartado del captulo a esbozar
posibles lineas futuras.
Como apartado final, relacionaremos las conclusiones y resultados entre s

generando unas conclusiones globales, donde se corroborar la consecucin
de los objetivos planteados al principio de esta Tesis. Tras este apartado
daremos por concluida la Tesis Doctoral.
8.2 Conclusiones
Las conclusiones principales se dividen en conclusiones respecto a las
interacciones alumno-sistema (evaluaciones) y alumno-alumno (foros),
conclusiones tras la propuesta de arquitectura que soporte un sistema para
facilitar la interoperabilidad de objetos de aprendizaje, respecto a la
especificacin de la ontologa propuesta y validacin del conjunto.
Respecto a las evaluaciones en teleformacin, podemos concluir que es

posible transformar las especificaciones existentes y mayoritariamente
utilizadas (IMS QTI) en una ontologa basada en OWL DL, as como
enriquecerla con conceptos de otras especificaciones (TeML) que
enriquecen la informacin a procesar. Tambin se demuestra la ventaja de
incluir las interacciones constructivistas en la informacin a almacenar en
los repositorios de contenidos, en lugar de dejar perder esa informacin en
el LMS. Se ha comprobado, a su vez, la falta de ontologas que describan a
los foros, cuando es un elemento en el que puede haber una gran cantidad de
informacin semiestructurada, y adems se ha demostrado que es una
herramienta muy til para la resolucin de dudas puntuales en las grandes
comunidades virtuales de aprendizaje.
A la hora de proponer la arquitectura, vemos como ptima una arquitectura

P2P por razones de escalabilidad y resistencia a fallos. Al ser una
arquitectura P2P, necesita nodos que estn interesados en formar parte de la
red durante mucho tiempo. En nuestro caso han sido los propios ofertantes
de Objetos Educativos los que realizan la tarea de mantener una estructura
mnima. Tambin nos damos cuenta que es muy importante atender a los
derechos de autor de los contenidos educativos de la red. Es por esto por lo
que se se han restringido los lugares de almacenaje del Objeto Educativo.
296
Concluimos a su vez que la arquitectura es una arquitectura para la web

semntica de uso general, puesto que sirve para la interoperabilidad de
cualquier ontologa OWL DL que queramos, debido a que no se ha
realizado ninguna restriccin ni suposicin sobre las clases descritas en la
ontologa..
Respecto a la especificacin de la ontologa hemos visto que el nivel de

lenguaje OWL DL optimiza, basndonos en las capacidades de clculo y
algoritmos actuales, la relacin entre la riqueza descriptiva y la posibilidad
de resolver las inferencias presentadas. Adems, se ha desarrollado una
ontologa que abarca los tres principales modos de aprendizaje, como vemos
en la figura 8.1, el enfoque conductista, el enfoque constructivista y
podemos considerar que el enfoque cognoscitivista se ofrece por medio de
los contenidos estticos.
Fig. 8.1. Inclusin de los distintas teoras de aprendizaje en la ontologa
Por ltimo, en la validacin hemos podido comprobar que las herramientas

para generar y trabajar con OWL son an inestables , ya que la temtica es
bastante novedosa. Ocurre esto tambin en los razonadores, donde parece
que actualmente Pellet es la mejor opcin para un sistema como el nuestro.
8.3 Lneas de trabajo futuras

Las lneas futuras propuestas se basan en los dos apartados principales de la
Tesis, que son la ontologa especificada para teleeducacin y la arquitectura
propuesta para la web semntica, y que nos permite explotar la ontologa
especificada.
Respecto a la ontologa, aunque se ha descrito en OWL DL, hemos visto

como la introduccin de reglas en SWRL mejora la expresividad del
lenguaje, por lo que sera interesante profundizar esta va ampliando la
297
ontologa especificada con reglas, de modo que el sistema fuera ms

inteligente. Tendremos que esperar a razonadores optimizados para SWRL
para que sea interesante abarcar esta tarea.
Tambin se propone realizar en un futuro ampliaciones puntuales de la

ontologa especificada, como puede ser el desarrollo en profundidad de otras
interacciones constructivistas, como son los trabajos o tareas en grupo, los
trabajos con documentos compartidos y las faqs. Incluso podran ampliarse
los distintos conceptos con la aparicin de nuevos tipos de preguntas en las
evaluaciones. Es realmente en los campos de las interacciones de los
distintos actores de una experiencia educativa donde hay espacio de
desarrollo, ya que sobre los contenidos estticos se ha trabajado mucho en
los ltimos aos y ya existen especificaciones aceptadas.
Otra oportunidad de investigacin que surge de esta Tesis es el estudio del

uso de la ontologa propuesta no slo para la interoperabilidad y bsquedas,
sino para que la entienda el propio LMS y pueda publicar directamente una
experiencia educativa, al estilo de lo que puede hacer un LMS con la
informacin del manifiesto.
En la propuesta de arquitectura tambin hay lneas de trabajo interesantes,

como son el desarrollo de un publicador de contenidos completo en lugar de
realizar una prueba de concepto como ha ocurrido en captulos anteriores.
Adems, se propone en un futuro implementar la DHT Semntica por medio
de una capa sobre una DHT clsica en la que se realicen las
transformaciones entre las arquitecturas, y evaluar parmetros de
rendimiento de esta estructura, por medio de simuladores de varios cientos
de nodos.
Incluso existe campo de desarrollo en la defincin del proceso de obtencin

y ensamblaje de los objetos educativos elegidos, ya que se propone una
metodologa variable en funcin del tamao del recurso. Tambin sera
interesante probar la arquitectura con otras ontologas OWL-DL para
comprobar su eficacia como arquitectura de web semntica en general.
Otra posible lnea sera trabajar con los futuros motores de inferencias, y
modificar los interfaces, de forma que no sea necesario utilizar DIG como
mtodo de comunicacin. Se podra implementar distintos agentes
inteligentes que ya solicitaran directamente al usuario informacin y le
presentaran un interfaz amigable para que el usuario pudiera generar la
consulta basndose en los conceptos definidos en la TBox de la ontologa.
298
Ser a partir de la mejora de algoritmos de inferencia y de mejoras en la

computacin de los motores cuando se produzca un verdadero despegue de
las tecnologa asociadas a la web semntica, como ocurri en su da con las
bases de datos relacionales.
BUSCAR (K1, TBox)
DHT SEMANTICA
AGENTE V = OWL URL
OWL
OWL URL
PUBLICADOR
SEMNTICOS
OWL
ALMACEN INFORMACION
SEMNTICA
.OWL
LO-A LO-B LO-C

Fig. 8.2. DHT Semntica
299
8.4 Conclusiones finales

Como conclusin final de esta Tesis vemos que hemos conseguido los
objetivos planteados al principio de la misma. Por una parte se han
estudiado y aplicado las ltimas tendencias en interoperabilidad de recursos
educativos por medio de lenguajes ontolgicos, incluyendo a su vez
informacin respecto a las interacciones de los usuarios por medio de los
foros y por medio de las evaluaciones. Esta informacin se almacena para su
uso posterior por parte de los agentes inteligentes.
Para alcanzar estos objetivos primero se han investigado el estado actual de

la web, desde la web sintctica a la web semntica, analizando la estructura
de capas existente para poder luego desarrollar este trabajo sobre una base
de conocimiento firme. Tambin se ha analizado el estado del arte en la
Teleeducacin desde el prisma de la web semntica, estudiando las
ontologas educativas extradas de los estndares y modelos de referencia
que tienen ms importancia en la actualidad. Adems, se ha profundizado en
los fundamentos lgicos que nos han permitido especificar la ontologa
propuesta y fundamentar la razn por la cual se ha escogido OWL como
lenguaje ontolgico en la Tesis.
Gracias al anlisis realizado sobre las ontologas educativas ms

importantes, hemos extrado las relaciones implcitas de las mismas, que nos
han servido para ser explicitadas en nuestra ontologa. De hecho, la
ontologa especificada en esta Tesis reutiliza los conceptos ya aceptados y
comprobados provenientes de otras ontologas, escogiendo los ms
adecuados para nuestros propsitos. Como ejemplo destacable, respecto a
las interacciones alumnos-sistema nos hemos basado en conceptos de
SCORM (relacin entre los resultados de evaluaciones y los objetivos
conseguidos), IMS QTI (conceptualizacin de preguntas, proceso de
obtencin de resultado y tipos de preguntas), TeML (sistema de feedbacks,
tipos de preguntas y relacin de preguntas con posibles respuestas, as como
dificultades de las evaluaciones) y IEEE 1484 (tipos de preguntas en las
evaluaciones y campos relacionados). En los casos que se ha constatado que
no exista ninguna ontologa reaprovechable para nuestros objetivos, ha sido
necesario construir nuevos conceptos y relaciones, que adems de ser
utilizados en esta Tesis podran servir tambin para estudios posteriores. La
reutilizacin de conceptos ya probados ha resultado de gran utilidad para
nuestros fines, ya que facilita la importacin de informacin a nuestro
sistema puesto que existen grandes similitudes conceptuales con la mayora
de sistemas basados en estos estndares.
300
De esta forma, tras enumerar las distintas teoras de aprendizaje que

queremos incluir en nuestro sistema (conductismo, cognoscitivismo y
constructivismo), se han tenido que describir las interacciones de los
usuarios ms importantes que se producen en un proceso formativo por
internet, es decir las interacciones alumno-sistema y las interacciones entre
usuarios, que no figuraban hasta el momento en ninguna de las ontologas
analizadas con el objetivo de permitir bsquedas para la reutilizacin. Dicha
informacin en nuestro sistema es accesible para los agentes inteligentes con
el objetivo de realizar bsquedas tanto por palabras clave como utilizando
motores de inferencia, ya que se ha definido, desarrollado y evaluado una
ontologa expresada en OWL DL con esas caractersticas. A raz de esto se
ha presentado tambin un ejemplo de bsquedas mixtas RDF/OWL, lo que
ampla an ms el campo de accin de los agentes inteligentes. Esta
definicin de bsqueda mixta ha resultado muy positiva a la hora de facilitar
las tareas de localizacin, ampliando enormemente las posibilidades de los
agentes.
Asimismo, se ha propuesto y definido una arquitectura de explotacin,

basada en el nuevo concepto de web semntica, de forma que pretendemos
que esta arquitectura impulse su uso en la teleeducacin. Hemos validado
tambin la ontologa especificada de forma que se han presentado distintas
posibilidades de uso de agentes inteligentes en la teleeducacin,
proponiendo un sistema de localizacin donde el agente presenta al usuario
posibilidades de bsqueda, el usuario define la bsqueda utilizando los
trminos ofrecidos por el agente y por ltimo el agente presenta los posibles
resultados al usuario. De esta forma se mejora considerablemente el
resultado obtenido respecto a una simple bsqueda por palabras clave.
Esta Tesis sienta las bases de una arquitectura que facilita la localizacin en
la web semntica de recursos educativos reutilizables para impulsar la
teleeducacin en todos sus mbitos. Para ello se basa en el anlisis riguroso
de las necesidades y estndares actuales, realizando una especificacin que
se ha validado para demostrar su utilidad en el campo de la interoperabilidad
de recursos educativos. Por todo esto, esperamos que esta Tesis sirva
tambin para desarrollos futuros en los que se implementen agentes
inteligentes con motores de inferencia ms avanzados y se pueda llevar a
cabo una arquitectura similar a la propuesta, en la que se facilite el acceso a
contenidos semnticos y se permitan grandes variaciones de carga. Tambin
esperamos que se desarrollen ontologas nuevas basadas en la ontologa
especificada en esta Tesis, de forma que se enriquezca el conocimiento de la
teleformacin por parte de los agentes inteligentes, revertiendo a su vez en
301
un mejor servicio para los usuarios que pretendan reutilizar contenidos

educativos.
302
Anexo 1. Glosario
Anexo 1. Glosario
303
Anexo 1. Glosario
Trminos y Acrnimos
ABox. parte de una base de conocimiento en lgica descriptiva relativa a las
instancias de clases.
Agente Inteligente. Toda entidad que percibe y acta sobre su entorno,
desarrollando cierto grado de inteligencia . En esta Tesis nos
referiremos a agente inteligente como las entidades no humanas que
nos facilitarn la bsqueda de recursos educativos, por medio de la
realizacin de inferencias sobre la base de conocimiento que han
adquirido en la web semntica.
AHA. Adaptative Hypermedia Architecture. Sistema que utiliza la web para
generar y mostrar redes semnticas.
AICC. Aviation Industry Computer-Based-Training Committee. Organismo
encargado de estandarizar la formacin basada en computadores de
la industria area.
AIMS. Agent-based Information Management System. Plataforma de
teleformacin basada en redes semnticas.
Ajax. Asynchronous JavaScript and XML. Tcnica de programacin de alto
nivel que utiliza componentes que se ejecutan en la web por medio
de Javascript en el cliente y comunicacin con el servidor va XML.
CDN. Content Distribution Network. Red de ordenadores en internet que
colaboran para distribuir contenidos de forma transparente al
usuario.
Clasificacin de una ontologa. Proceso de inferencias por el que se
explicitan todas las relaciones de herencia entre clases de una
ontologa.
Consistencia de una ontologa. Proceso de inferencias por el que se
confirma que no existe ninguna incongruencia en la ontologa, es
decir, que todas las clases de la misma pueden tener instancias.
DIG. Description Logic Implementation Group Interface. Interfaz que
define un protocolo de intercabio de ontologas descritas en lgica
descriptiva, que suelen aceptar la mayora de razonadores lgicos.
DL. Lgica descriptiva. Subtipo de lgica de primer orden donde se separa
completamente entre clases, propiedades e individuos, y las
relaciones tienen un nico sujeto y un nico predicado.
DTD. Document Type Definition. Lenguaje para definir la estructura de un
documento XML.
EGA. Extreme Groups Approach. Sistema de obtencin de resultados
estadsticos basado en el estudio de los valores extremos de una
muestra.
304
Anexo 1. Glosario
FOL.First Order Logic. Lgica de primer orden. Lgica predicativa que

permite la relacin entre conteptos por medio de propiedades.
GPL. GNU General Public License. Licencia de software libre.
HTTP/GET. Mtodo de solicitud de un recurso en el protocolo HTTP en el
que el propio mensaje de peticin incial indica la solicitud por
completo.
HTTP/POST. Mtodo de solicitud de un recurso en el protocolo HTTP en
el que es necesario un segundo envo con ms informacin por parte
del solicitante para definir completamente la peticin solicitada
solicitado.
IEEE. Institute of Electrical and Electronics Engineers. Organizacin
internacional sin nimo de lucro que busca el desarrollo de la
tecnologa. IEEE prepara y publica estndars en los distintos
campos, como la educacin.
IEEE LTSC. IEEE Learning Technology Standards Committee. Comit
encargado del estudio, desarrollo y publicacin de los estndares de
IEEE relativos al aprendizaje.
IMS o IMS Global. Instructional Managed Systems.Organizacin sin
nimo de lucro dedicada a presentar especificaciones que faciliten la
interoperabilidad de los sistemas de aprendizaje y los contenidos de
aprendizaje.
IMS CMI. Utilizacin dentro de IMS de la especificacin de AICC
denominada Content Management Interface. Esta especificacin es
relativa a las comunicaciones entre el aprendiz y el LMS.
IMS CP. IMS Content Packaging. Especificacin sobre el
empaquetamiento de contenidos de aprendizaje
IMS LD. IMS Learning Design. Especificacin para ladefinicin de
unidades de aprendizaje y para definir reglas de paso de objetivos.
IMS QTI. IMS Question & Test Interoperability. Especificacin relativa a
las distintas evaluaciones en un curso on-lien.
IMS SS. IMS Simple Sequencing. Especificacin que trata de definir las
reglas de navegacin en una experiencia formativa.
IPSec. Internet Protocol security. Extensin del protocolo IP con cifrado
para permitir servicios de autenticacin.
JSF. JavaServer Faces Technology. Tecnologa de programacin Java para
servidores web basado en el paradigma modelo vista. Se construye
sobre JSP.
JSP JavaServer Pages Technology. Tecnologa de programacin Java para
servidores web que permite generar contenido dinmico para la web.
LMS. Learning Management System. Software ejecutado en uno o varios
servidores web que permite la gestin de un curso on-line.
305
Anexo 1. Glosario
LOM. Learning Object Metadata. Modelo de informacin que define los

metadatos de los distintos objetos educativos. El estdard ms
aceptado es IEEE 1484.12.1 2002 (IEEE LOM).
LOWID. Identificador de nodo en una red P2P como eMule que no puede
aceptar conexiones inesperadas desde la web, normalmente por estar
detrs de un firewall. Los nodos con LOWID son penalizados en los
sistemas P2P ya que no permiten utilizar sus recursos de forma
inesperada.
LP. Lgica proposicional. Lgica en que los elementos relacionados por
operadores lgicos son indivisibles, siendo la lgica ms sencilla
tratada en esta Tesis.
MATHML. Mathematical Markup Language. Lenguaje basado en XML
para describir conceptos y operaciones matemticas.
NAT. Network address translation. Traductor de direcciones de red
utilizado normalmente para permitir a un conjunto de ordenadores
de un red privada acceder a internet utilizando una nica direccin
IP para todos..
OWA. Open World Assumption. Suposicin en las inferencias lgicas que
se basa en el hecho que si no puedo demostrar que algon no es
verdadero no significa que es falso. Esta suposicin es necesaria
cuando se hacen inferencias sobre bases de conocimiento que se van
ampliando con nueva informacin.
OWL. Web Ontology Language. Especificacin de W3C para la insercin
de ontologas en la web. Lenguaje web basado en RDF para la
definicin de ontologas.
OWL-S. Ontologa para servicios web basada en OWL.
P2P. Peer to Peer. Atributo de una red que indica que todos los elementos
pueden compartir una o todas las funciones del sistema, evitando
centralizaciones.
RDF. Resource Description Framework. Especificacin de W3C para la
realizacin de aserciones en la web. Lenguaje que permite relaciones
un recurso sujeto con un recurso objeto por medio de un tercer
recurso denominado predicado.
RDF-QEL. RDF-based Query Exchange Language. Lenguaje para solicitar
bsquedas en documentos RDF
RFC. Request For Comments. en W3C son documentos que realizan nuevas
propuestas, protocolos o definiciones. Internet Engineering Task
Force (IETF) adopta algunos de estos documentos como estndars
para Internet. RIA. Rich Internet Aplication. Tecnologas que se
basan en simular la mayora de funcionalidades de aplicaciones
locales que ejecutaramos normalmente desde nuestro ordenador en
306
Anexo 1. Glosario
una aplicacin web, normalmente por medio de tcnicas de

programacin como Ajax.
RQL. RDF Query Language. Lenguaje para solicitar bsquedas en
documentos RDF
SCO. Sharable Content Object. En el modelo SCORM se refiere a cualquier
objeto educativo que sea lo suficiente independiente para se
compartido.
SCORM. Shareable Content Object Reference Model. Modelo que reutiliza
un conjunto de estndars y especificaciones para la teleformacin.
SGML. Standard Generalized Markup Language. Lenguaje generalizado
para generacin de otros sublenguajes de marcas, como XML.
SKOS. Simple Knowledge Organisation System. Lenguajes diseados para
la representacin de tesaurios y clasificaciones, basado en RDF y
RDFS.
SSL. Secure Sockets Layer, actualmente evolucionada a Transport Layer
Security (TLS). Protocolo que permite la comunicacin segura en
internet.
TLS, ver SSL
SWRL. Semantic Web Rule Language. Lenguaje fruto de la unin de OWL
y RULEML para la generacin de ontologas utilizando lgica
descriptiva y reglas.
TBox. Parte de una base de conocimiento en lgica descriptiva relativa a las
clases y su estructura, a modo de taxonoma.
TTL. Time To Live. Parmetro de los paquetes de informacin en una red
que indica normalmente el nmero de saltos que restan para
desaparecer si no ha alcanzado su destino.
UML. Unified Modeling Language. Es un lenguaje de especificacin para
modelacin de objetos. Se utiliza principalente en el campo de
programacin basada en objetos.
UNA. Unique Name Assumption. Suposicin en las inferencias lgicas que
se basa en que cada recurso tiene un nico URI que lo identifica, por
lo que podemos concluir que dos objetos representados por distintas
URIs no pueden ser el mismo objeto.
URI. Uniform Resource Identifier. Secuencia de caracteres que identifica un
recurso abstracto o fsico.
URL. Uniform Resource Locator. URI que permite adems localizar de
forma automtica el recurso.
W3C World Wide Web Consortium. Es la principal organizacin
internacional que define los estndars para la web.
307
Anexo 1. Glosario
XHTML. Extensible HyperText Markup Language. Lenguage de marcas

basado en XML, con la misma utilidad que HTML pero ms extricto
en la sintaxis.
XML. Lenguaje de marcas recomendado por W3C que se utiliza
generalmente para la transmisin de datos por la web
XMLS. XML Schema. Lenguaje para definir la estructura de un documento
XML, expresado a su vez en XML, en contraste con DTD que tiene
una sintaxis propia.
308
Anexo 2. Referncias
Anexo 2. Referencias
309
Artculos e Informes
[ADL04a] SCORM. Advanced Distributed Learning (ADL) Sharable Content
Object Reference Model (SCORM). Content Aggregation Model
(CAM) Version 1.3.1. Julio 2004.
[ADL04b] SCORM. Advanced Distributed Learning (ADL) Sharable Content
Object Reference Model (SCORM). Run-Time Environment (RTE)
Version 1.3.1. Julio 2004.
[ADL04c] SCORM. Advanced Distributed Learning (ADL) Sharable Content
Object Reference Model (SCORM). Sequencing and Navigation (SN)
Version 1.3.1. Julio 2004.
[AICC04] AICC CMI001, CMI Guidelines for Interoperability, Version 4. Agosto
2004.
[AKE04] A. Akella, J. Pang, B. Maggs, S. Seshan, A. Shaikh. A Comparison of
Overlay Routing and Multihoming Route Control. ACM Sigcomm.
Septiembre 2004.
[ANA05] R. Anane et al. A Web Services Approach to Learning Path
Composition. Proceedings of the 5th IEEE International Conference on
Advanced Learning Technologies (ICALT05). Taiwan. Julio 2005.
[ANI04] L. Anido, J. Rodrguez, M. Caeiro, J. Santos. A Focal Access Point to
Follow the Standardization of Learning Technologies. Proceedings of
the 4th IEEE International Conference on Advanced Learning
Technologies (ICALT04). Finlandia. Agosto 2004.
[ANK04] A. Ankilenkar, M. Paolucci et al OWL-S: Semantic Markup for Web
Services. White paper for OWL. 2004.
[ALO05] F.Alonso, G. Lpez, D. Manrique, B. Ruiz. XML repositories definition
for adaptive e-learning courses. 3rd International Conference on
Multimedia and Information. Junio 2005.
[ALO06] J.A. Alonso, M.J. Hidalgo, F.J. Martin, J.L. Ruiz. Formalizacin de la
lgica descriptiva ALC en PVS. Grupo de Lgica Computacional.
Universidad de Sevilla. Marzo 2006.
[ANS03] E. Ansell, J. Park. Tracking Tech Trends. Education Week, 22(5). Pp.
43-44, 48. Julio 2003.
[ARE01] C. Areces, M. de Rijke. From Description to Hybrid Logics, and Back.
In Wolter, F., Wansing, H., de Rijke, M., and Zakharyaschev, M.,
editors, Advances in Modal Logic, CSLI Publications. Pp. 1736. 2001.
[ARO03] L. Aroyo, S. Pokraev, R. Brussee. Preparing SCORM for the Semantic
Web. Paper presented at the International Conference on Ontologies,
Databases and Applications of Semantics (ODBASE03). Italia.
Noviembre 2003.
[ARO04] L. Aroyo, D. Dicheva. The New Challenges for E-learning: The
Educational Semantic Web. Educational Technology & Society, 7 (4),
Pp: 59-69. 2004
310
Anexo 2. Referncias
[BAL04] M. Baldoni, C. Baroglio, V. Patti, and L. Torasso. Reasoning about

learning object metadata for adapting SCORM courseware. EAW04:
Methods and Technologies for personalization and Adaptation in the
Semantic Web. Pp 413. Holanda. 2004.
[BAL96] S. Balli, L. Diggs, Learning to Teach with Technology: A Pilot Project
with Preservice Teachers Educational Technology, 36, 1, Pp 56-61.
Febrero 1996.
[BAR04] J.P. Baraldi, D.O. Romero, C.M. Rinaldi. Gateway para el Reciclaje de
Sistemas E-learning que no cumplen con SCORM. LatinEduca 2004.
[BECH03] S. Bechhofer. The DIG Description Logic Interface: DIG/1.1.
Febrero 2003.
[BECH03] S. Bechhofer, I. Horrocks, P. Patel-Schneider. Tutorial on OWL. 2nd
International Semantic Web Conference. EEUU. Octubre 2003.
[BEN03] D. Benz. Description Logics, the logical foundation of the Semantic
Web. Seminar on Semantic Web Descrition Logics. Noviembre 2003.
[BES05] P. Besana, D. Robertson, M. Rovatsos.Exploiting interaction contexts in
P2P ontology mapping. 2nd. International Workshop on Peer to Peer
Knowledge Management. EEUU. Julio 2005.
[BHA05] K. Bhatia. Peer-To-Peer Requirements On The Open Grid Services
Architecture Framework. OGSAP2P Research Group. Julio 2005.
[BID04] M. Biddulph. Crawling the Semantic Web. Journal of Web Semantics.
2004.
[BRA85] R.J. Brachman, J. Schmolze. An Overview of the KL-ONE Knowledge
Representation System, Cognitive Science 9. 1995.
[BUY02] R. Buyya. Convergence Characteristics for Clusters, Grids, and P2P
networks. Panel at the P2P conference. Suecia.
[CAE04] M. Caeiro, L. Anido, M. Llamas. Towards IMS-LD Extensions to
Actually Support Heterogeneous Learning Designs. A Pattern-based
Approach. Proceedings 4th IEEE International Conference on
Advanced Learning Technologies (ICALT04). Finlandia. Agosto 2005.
[CAE05] M. Caeiro, L. Anido, M. Llamas. A Perspective and Pattern-based
Evaluation Framework for EMLs Expressiveness for Collaborative
Learning: Application to IMS LD. Proceedings 5th IEEE International
Conference on Advanced Learning Technologies (ICALT05). Taiwan.
Julio 2005.
[CAP04] O. Caprotti, M. Dewar, D. Turi. Mathematical Service Matching Using
Description Logic and OWL. Mathematical Knowledge Management:
Third International Conference, Proceedings. Polonia. Septiembre 2004.
[CHA04] W. Chang, H. Hsu, T.K. Smith, C. Wang. Enhancing SCORM metadata
for assessment authoring in e-Learning. Journal of Computer Assisted
Learning 20. Pp 305-316. Agosto 2004.
[CHA98]V.K. Chaudhri, A. Farquhar. Especificacin Open Knowledge Base
Connectivity 2.0.3. Abril 1998.
311
[CON01] D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P.F.

Patel-Schneider, L. A. Stein. DAML+OIL Reference Description
Marzo 2001.
[COO02] B.F. Cooper, H. Garcia-Molina. Peer-to-peer resource trading in a
reliable distributed system. 1st International Workshop on Peer-to-Peer
Systems. EEUU. Marzo 2002
[CRE05]A. Cregan, M. Mochol, D. Vrandecic, S. Bechhofer. Pushing the limits
of OWL, Rules and Protege. A simple example. OWL Workshop on
Experiences & Directions. Irlanda. Noviembre 2005.
[DAM05] V. Damjanovic, M. Kravcik, V. Devedzik. eQ: An Adaptive
Educational Hypermedia-based BDI Agent System for the Semantic
Web. Proceedings of the Fifth IEEE International Conference on
Advanced Learning Technologies (ICALT05). Taiwan. Julio 2005.
[DEH06] S. Dehors, C. F. Zucker, R. D. Kuntz Reusing Learning Resources
based on Semantic Web Technologies. Proceedings 6th International
Conference on Advanced Learning Technologies. ICALT. ISBN 978-0-
7695-2632-4. EEUU. 2006.
[DICK04] I. Dickinson. Implementation experience with the DIG 1.1
specification. HP Technical Report. Mayo 2004.
[DOD01] P. Dodds (editor). The SCORM overview. ADL Sharable Content
Object Reference Model. 2001.
[DRI04] L.P. Dringus, T. Ellis. Using data mining as a strategic for assessing
asynchronous discussion forums. Computers & Educations 45. Pp:
141-160. Mayo 2004
[EDE06] A.H. Eden, Y. Hirshfeld, R. Kafman. Abstraction Classes in Software
Design. IEE Software Vol. 153, No. 4. Pp: 163182. Agosto 2006.
[EDT] Edutools: iniciativa de WCET the Western Cooperative for Educational
Telecommunications para realizar comparaciones en la comunidad de
e-Learning. http://www.edutools.info.
[ELL05] H.Ellis. A Collaborative Approach to a Course on the Semantic Web.
35th ASEE/IEEE Frontiers in Education Conference. EEUU. Octubre
2005.
[FAR06] R.Farr et al. Notas de clases para Introduccin a la Lgica. Universidad
Politcnica de Catalua. Diciembre 2006.
[FED05] Fedora Open Source Repository Software:White Paper. October 2005.
http://www.fedora.info
[FEL02] P.A. Felber, E.W. Biersack, L. Garcs-Erice, K.W. Ross, G. Urvoy-
KellerData Indexing and Querying in DHT Peer-to-Peer Networks.
2002.
[FIE00] Fielding, Roy Thomas. Architectural Styles and the Design of Network-
based Software Architectures. Doctoral dissertation, Captulo V.
University of California. EEUU 2000.
[FOS03] I. Foster, A. Tamnitchi. On Death, Taxes, and the Convergence of Peer-
to-Peer and Grid Computing. 2003.
312
Anexo 2. Referncias
[FOWL05] C. Fowler. Revisiting the Delta ontology. Disponible en

http://www.essex.ac.uk/chimera/
[FRA01] E. Franconi. Description logics lecture notes. Pres. slides, University of
Manchester, Marzo 2002.
[GAM01] C. Qu, J. Gamper, W. Nejdl, A Collaborative Courseware Generating
System Based on WebDAV, XML, and JSP, IEEE International
Conference in Advanced Learning Technologies 2001 (ICALT 2001),
Pp. 441-442. USA. Agosto 2001.
[GAR03] D. Garlan, M. Shaw. An Introduction to Software Architecture,
Advances in Software Engineering and Knowledge Engineering,
Volumen I. World Scientific. EEUU. 1993.
[GAR04] A. Garcia Jimnez. Instrumentos de representacin del conocimiento:
Tesauros frente a Ontologas. Anales de Documentacin, nmero 007.
Pp: 79-95. Universidad de Murcia.
[GAR06] T. Gardiner, I. Horrocks, D. Tsarkov. Automated Benchmarking of
Description Logic Reasoners. Mayo 2006.
[GER03] J. Gerke, D. Hausheer, J. Mischke, B. Stiller. An Architecture for a
Service Oriented Peer-to-Peer System (SOPPS) Praxis der
Informationsverarbeitung und Kommunikation. ETH. Pp: 90-95. Suiza.
2003.
[GOL96] M. Goldberg, S. Salari, P. Swoboda. World Wide Web Course Tool: An
Environment for Building WWW-Based Courses, Computer Networks
and ISDN Systems, 28. Pp: 12191231. Paises Bajos. 1996.
[GOR93] M.J.C. Gordon, T. F. Melham. Introduction to HOL: a theorem proving
environment for hier order logic. Cambridge University Press. 1993.
[GRUB93] T. R. Gruber. Towards Principles for the Design of Ontologies Used
for Knowledge Sharing". In Formal Ontology in Conceptual Analysis
and Knowledge Representation. Kluwer Academic Publishers. 1994.
[GUE05] A. Guerrero, V. A. Villagr, J.E. Lpez. Definicin del comportamiento
de gestin de red con reglas SWRL en un marco de gestin basado en
ontologas OWL. Irlanda. Octubre 2006.
[GUO06] W. Guo, D. Chen. Semantic Approach for e-learning System.
Proceedings of the First International Multi-Symposiums on Computer
and Computational Sciences. China. Junio 2006.
[GUP01] G. Gupta, E.Pontelli, K.Ali, M. Carlsson, M. Hermenegido. Parallel
Execution of Prolog Programs: A Survey. ACM Transanctions on
Programming Languages and Systems, Vol 23, Num 4, Pp: 472, 602.
ACM Press, Julio 2001.
[HAA04] P. Haase, et al. Bibster A Semantics-Based Bibliographic Peer-to-
Peer System. 3rd International Semantic Web Conference (ISWC
2004). Pp. 122136. Japn. Noviembre 2004.
[HAA05] V. Haarslev, R. Mller, M. Wessel. Description Logic Inference
Technology: Lessons Learned in the Trenches. Proc. International
Workshop on Description Logics. 2005.
[HAR03] Harth, Andreas. An Integration Site for Semantic Web Metadata. 2003.
313
[HAT02] M. Hatala, G. Richards. Learning Object Repository Technologies for

TeleLearning: The Evolution of POOL and CanCore. Informing
Sciencia + IT Education Conference. Irlanda. Junio 2002.
[HAY01] Patrick Hayes, Christopher Menzel A Semantics for the Knowledge
Interchange Format. 2001.
[HAY04] M. Haynos. Perspectives on grid: Grid computing - next-generation
distributed computing. What's different between grid computing and
P2P, CORBA, cluster computing, and DCE?. Enero 2004. http://www-
128.ibm.com/developerworks/grid/library/gr-heritage/
[HAR03] A. Hart. An Integration Site for Semantic Web Metadata. 2003.
[HAT02] M. Hatala, G. Richards. Making a Splash: a Heteregeneous Peer-To-
Peer Learning Object Repository Technology. 2002.
[HAY01] P. Hayes, C. Menzel A Semantics for the Knowledge Interchange
Format. 2001.
[HAY04] M. Haynos. Perspectives on grid: Grid computing -- next-generation
distributed computing. What's different between grid computing and
P2P, CORBA, cluster computing, and DCE?. Enero 2004. http://www-
128.ibm.com/developerworks/grid/library/gr-heritage .
[HAR03] R. Hartwig, M. Herczeg. A Process Repository for the Development of
E-Learning Applications Proceedings of the The 3rd IEEE
International Conference on Advanced Learning Technologies
(ICALT03). Grecia. Junio 2003.
[HEF99] J. Heflin, J. Hendler, S. Luke. SHOE: A Knowledge Representation
Language for Internet Applications. Technical Report, University of
Maryland, 1999.
[HEN00] J. Hendler, D. L. McGuinness. The DARPA Agent Markup Language.
IEEE Intelligent Systems, 15. 2000.
[HOR03] I. Horrocks, P.F. Patel-Schneider, F. van Harmelen. From SHIQ and
RDF to OWL: The Making of a Web Ontology Language. 2003.
[HOR04] M. Horridge, H. Knublauch et al. A Practical Guide To Building OWL
Ontologies Using The Protg-OWL Plugin and CO-ODE Tools. The
University Of Manchester. Reino Unido. Agosto 2004.
[HOW04] S.L. Howell. E-Learning and Paper Testing: Why the Gap?.
EDUCASE Quaterly, 4 Pp: 8-10. 2004.
[HUE97] J. L. Hueso, A. Martnez, R. Romero, J. R. Torregrosa . Web y
Multimedia al servicio de la enseanza de las Matemticas. Edutec97.
2007. http://www.ieev.uma.es/edutec97/edu97_c2/2-2-16.htm.
[IAN02] I. Horrocks, U. Sattler. Logical Foundations for the Semantic Web.
University of Glasgow. 2002.
[IAN03] I. Horrocks and P. F. Patel-Schneider. Three theses of representation in
the semantic web. In Proc. of the Twelfth International World Wide
Web Conference (WWW 2003). 2003
[IEEECMI] IEEE 1484.11.1, Standard for Learning Technology. Data Model for
Content Object Communication 2005. 2005. http://ltsc.ieee.org/
314
Anexo 2. Referncias
[IEEEECMA] IEEE 1484.11.2 Standard for Learning Technology ECMAScript

Application Programming Interface for Content to Runtime Services
Communication. Noviembre 2003. http://ltsc.ieee.org/
[IEEE1471] IEEE Std 1471-2000 IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems .2000.
[IMS03a] IMS Abstract Framework: White Paper. Version 1.0. Julio 2003.
[IMS03b] IMS Abstract Framework: Applications, Services and Components.
Version 1.0. Julio 2003.
[IMS03c] IMS Abstract Framework: Glosary. Version 1.0. Julio 2003.
[IMSCP04] IMS Content Packaging Information Model, Version 1.1.4. Final Spec.
Octubre 2004. http://www.imsglobal.org/content/packaging/index.html.
[IMSRDCEO] IMS Reusable Definition of Competency or Educational Objective -
Information Model Version 1.0 Final Specification. Octubre 2002.
www.imsglobal.org.
[IVO06] C. Iborra. Lgica y Teora de Conjuntos. Apuntes de la Universidad de
Valencia. Octubre 2006.
[JSR140] Java Specification Request 170. Content Repository APIfor Java
Technology. version 1.0.1. Marzo 2006.
[JUL00] V. Julian, V. Botti. Agentes Inteligentes: el siguiente paso en la
Inteligencia Artificial. NOVATICA . Junio 2000.
[JXTA04] JXTATM Technology: Creating Connected Communities. Enero 2004.
www.jxta.org/
[JXTA05]JXTA v2.3.x: Java Programmers Guide. Abril 2005. www.jxta.org/.
[KAL04] A. Kalyanpur, E. Sirin et al. Hypermedia Inspired Ontology Engineering
Environment: SWOOP. International Semantic Web Conference.
Japn. 2004.
[KAL05] A. Kalyanpur, E. Sirin et al. Swoop: A Web Ontology Editing
Browser. Elsevier's Journal Of Web Semantics (JWS), Vol. 4 Issue 1.
2005.
[KEL39] T.L. Kelly. The selection of upper and lower groups for the validation of
test items. Journal of Educational Psychology. Pp: 30, 17-24. 1939.
[KER04] R. Keralapura, N. Taft, C.Chuah, G. Iannaccone. Can ISPs Take the
Heat from Overlay Networks?. ACM HotNets Workshop. EEUU.
Noviembre 2004.
[KIF95] M. Kiefer, G. Lausen, James Wu. Logical Foudations of Object-Oriented
and Frame-Based Languages Journal of ACM 1995, vol 42. Pp: 741-
842. 1995
[KIM05] T.Kim, M. Kim, G. Park. On Employing Ontology to e-Learning.
Proceedings of the Fourth Annual ACIS International Conference on
Computer and Information Science (ICIS05). 2005.
[KLEE98] J. Kleeman, Now is the Time to Computerize Pen and Paper Tests. A
White Paper. 1998. http://www.questionmark.com/
[KNU04]H. Knublauch, M.A. Musen. Editing Description Logic Ontologies with
the Protege OWL Plugin. Proceedings of the 2004 International
315
Workshop on Description Logics, Whistler, British Columbia. Canada.

2004.
[KRD04] N. Krdzavak. Description Logics Reasoning in Web-Bases Education
Environments. Adaptive Hypermedia and Collaborative Web-based
Systems (AHCW04). Alemania. Junio 2004.
[LAN02] S. Langridge. Pingback 1.0 specification. 2002.
http://www.hixie.ch/specs/pingback/pingback-1.0
[LAN96] J. Laney, Going the Distance: Effective Instruction Using Distance
Learning. Educational Technology. Pp: 36, 2, 51-54. 1996.
[LLO96] M.J.G. Lloyd, K. McCottery, The Introduction of Computer Based
Testing on an Engineering Technology Course, Assessment and
Evaluation in Higher Education. Pp: 21, 1, 83-90. 1996.
[LSSI02] LEY 34/2002, de 11 de julio, de Servicios de la Sociedad de la
Informacin y de comercio electrnico. Art 12.
[LTSC02] IEEE Standard for Learning Object Metadata. 2002.
[LUG02] George F. Luger. Artificial Intelligence, Structures and Strategies for
Complex Problem Solving. 4 edicin. Ed. Pearson Education Limited,
2002.
[MAC98] D. Mackenzie, TRIADS System,. 1998. http://www.derby.ac.uk/assess
[MAK02] Making Sense of Learning Specifications & Standards: A decision
Makers Guide to their Adoption The Masie Center. Marzo 2002.
[MAN02] V. Manso, Herramienta de Teleeducacin para Evaluacin basado en
XML. Trabajo de Final de Carrera codirigido por R. Romero y C.
Palau. 2002.
[MAN02B] V. Manso, J.M. Raga, R. Romero, C. E. Palau et al, An XML
Approach for Assessment in Education. IASTED International
Conference on Applied Informatics. Austria. 2002.
[MAO05] Y. Mao et al. Sub-Ontology Evolution for Service Composition with
Application to Distributed e-Learning. Proceedings of the 17th IEEE
International Conference on Tools with Artificial Intelligence
(ICTAI05). China. Noviembre 2005.
[MAR02] Philippe Martin. Knowledge Representation, Sharing and Retrieval on
the Web. Distributed System Technology Centre. Australia. 2002.
[MAU96] M. Mauldin. The Formative Evaluation of Computer-Based Multimedia
Programs, Educational Technology. Pp: 36, 2, 36-40. 1996.
[MAY02] P. Maymounkov, D. Mazieres. Kademlia: A Peer-to-peer Information
System. Based on the XOR Metric. 2002.
[MCC05] P. McCarthy. Search RDF data with SPARQL. Mayo 2005.
http://www-128.ibm.com/developerworks/xml/library/j-sparql/.
[MIL05] A. Miles, D. Brickley. SKOS Core Guide. W3C Working Draft 2.
Noviembre 2005.
[MODX06] BBphp Team. MODX: XML Modification Description Format.
2006.
[MON02] Monforte C., Vierlinger U. "The Role of the Facilitator in eLearning ".
Procs. SEFI Annual conference. Italia. 2002.
316
Anexo 2. Referncias
[MOO89] Moore, M. G. Three types of interaction. The American Journal of

Distance Education . Pp: 1-6. 1989.
[MOS97] M. Moser, et al. SETHEO and e-SETHEO the CADE-13 systems.
Journal of Automated Reasoning,18(2). Pp:237246. 1997.
[NEI02] W. Nejdl, B. Wolf et al. EDUTELLA: A P2P Networking Infrastructure
Based on RDF. World Wide Web Conference WWW2002. Hawai
2002.
[NEW96] T. Newby, D. Stepich, J. Lehman, J. Russell. "Instructional Technology
for Teaching and Learning: Designing Instruction, Integrating
Computers, and Using Media". Prentice-Hall, Inc., Englewood Cliffs,
EEUU. 1996.
[NON95] I. Nonaka, H. Takeuchi. The knowledge creating company. How
japanese companies create the dynamics of innovation. Oxford
University Press. 1995.
[NOY00] N. F. Noy, R. W. Fergerson, M. A. Musen. The knowledge model of
Protege-2000: Combining interoperability and flexibility. 2th
International Conference on Knowledge Engineering and Knowledge
Management (EKAW'2000). France. 2000.
[NOY01] N. F. Noy, D. L. McGuinness. Ontology Development 101. Standford
University. 2001.
[ORE05] T. OReilly. What Is Web 2.0. Design Patterns and Business Models for
the Next Generation of Software. Septiembre 2005.
[OWL04a] J. Heflin. OWL Web Ontology Language Use Cases and
Requirements. W3C Recommendation. Febrero 2004.
[OWL04b] M. Dean, G. Schreiber. (eds). OWL Web Ontology Language
Reference. W3C Recommendation. Febrero 2004.
http://www.w3.org/TR/owl-ref/.
[PAL03] C.E. Palau, V. Manso et al. An XML Approach for Assessment in
Education. International Journal of Computers & Applications. ISSN
1206-212X. Acta Press. Pp: 24-37. 2003.
[PAL04] C.E. Palau , R. Romero, V. Manso, J.C. Guerri, M. Esteve. Semantic
Web for Re-usability in Open and Distance Learning. Web Based
Education 2004. Alemania. 2004.
[PAL06] R. Palma, P. Haase. Oyster - Sharing and Re-using Ontologies in a Peer-
to-Peer Community. Proceedings of the 15th International Conference
on World Wide Web. Escocia. Mayo 2006.
[PAL99] C. Palau, M. Esteve, J. C. Guerri, Educational Uses of the WWW: An
Evaluation Tool, Word Wide Web, vol. 2, n 4, Pp: 231-249. Diciembre
1999.
[PAN02] J. Z. Pan, I. Horrocks. Reasoning in the SHOQ(Dn) Description Logic.
2002.
[PAN05] Z. Pan. Benchmarking DL Reasoners Using Realistic Ontologies.
OWL Workshop on Experiences & Directions. Irlanda. 2005.
[PAO03] M. Paolucci, K. Sycara. Autonomous Semantic Web Services. IEEE
Computer Society. Octubre 2003.
317
[PAU94] L.C. Paulson. Isabelle: A Generic Theorem Prover. 1994.

[PER05] M. Perry et al. Peer-to-Peer Discovery of Semantic Associations. 2nd.
International Workshop on Peer to Peer Knowledge Management.
EEUU. Julio 2005.
[QMK06] Question Mark Computing Ltd., Question Mark Web,. 2006.
http://www.questionmark.com/.
[QTI06] IMS Question and Test Interoperability. Version 2.1 Public Draft
Specification. 2006. http://www.imsglobal.org/question/.
[QTI06b] IMS Question and Test Interoperability. XML Binding. 2006.
http://www.imsglobal.org/question/.
[QUIT] http://chemware.co.nz/quizit.htm.
[RACER05] RacerPro reference manual. Version 1.9. Racer Systems Gmbh & Co.
Diciembre 2005.
[RACER05B] RacerPro Users Guide. Version 1.8. Racer Systems Gmbh & Co.
Abril 2005.
[RAG02] J.M. Raga. Herramienta Cooperativa para Trabajo en Grupo
Desarrollada en Java Basada en XML. Trabajo de Final de Carrera
codirigido por R. Romero y C. Palau. 2002.
[REB04] El estndar SCORM para EaD (Educacin a Distancia). Tesina del
Mster en Enseanza y Aprendizaje Abiertos y a Distancia. Universidad
Nacional de Educacin a Distancia. Diciembre 2004.
[REC05] A. Rector et al. Ontology Design Patterns and Problems: Practical
Ontology Engineering using Protg-OWL. 4th International Semantic
Web Conference (ISWC). Irlanda. Noviembre 2005.
[REY06] M. Rey, A. Fernndez, R. Diaz, J. J. Pazos. Extending SCORM to
Create Adaptive Courses. First European Conference on Technology
Enhanced Learning (EC-TEL 2006). Grecia. Octubre 2006.
[RFC1855] Netiquette Guidelines. http://www.ietf.org/rfc/rfc1855.txt
[RFC2440] OpenPGP Message Format. http://www.ietf.org/rfc/rfc2440.txt
[RFC2718] Guidelines for new URL Schemes. http://www.ietf.org/rfc/rfc2718.txt
[RFC3023] XML Media Types. http://www.ietf.org/rfc/rfc3023.txt
[RFC3275] (Extensible Markup Language) XML-Signature Syntax and Processing.
http://www.ietf.org/rfc/rfc3275.txt
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax.
http://www.ietf.org/rfc/rfc3986.txt.
[RIA02] A. Riazanov, A. Voronkov. The Design and Implementation of
Vampire. AI Communications,15. 2002.
[ROM02] R. Romero. Aplicaciones Cooperativas para Teleeducacin basadas en el
modo de comunicacin Multicast. Trabajo de Investigacin del
programa de Doctorado de Ingeniera de Telecomunicacin. 2002.
[ROM06] R. Romero, V. Manso, C .Palau. Preparing Proprietary Systems for
Continuous Education e-Learning for inter-operatibility: exporting to
SCORM. Proceedings 6th International Conference on Advanced
Learning Technologies. ICALT 2006. Holanda. 2006.
318
Anexo 2. Referncias
[ROM99] R. Romero. Implementacin y desarrollo de un sistema de simulacin

en entorno Web. Trabajo Final de Carrera de Ingeniera de
Telecomunicacin. 1999.
[ROU03] M. Roussopoulos et al. 2 P2P or not 2 P2P?. 2003.
[ROU05] D. Roure, N.R. Jennings, N.R. Shadbolt The Semantic Grid: Past,
Present, and Future. Proceedings of the IEEE, Vol 93, nmero 3.
Marzo 2005.
[RUS96] S. Russell. Inteligencia Artificial: un enfoque moderno. Prentice - Hall.
Mxico. 1996.
[RUT05] A. Ruttenberg, J. A. Rees, J. S. Luciano. Experience Using OWL DL for
the Exchange of Biological Pathway Information. OWL Workshop on
Experiences & Directions. Irlanda. Noviembre 2005.
[SAN05] J.M. Santos, L. Anido, M. Llamas. Design of a Semantic Web-based
Brokerage Architecture for the E-learning Domain. A Proposal for a
Suitable Ontology. 35th ASEE/IEEE Frontiers in Education
Conference. EEUU. Octubre 2005.
[SAMP02] D. Sampson, C. Karagiannidis, F. Cardinale. An Architecture for
Web-based e-Learning Promoting Re-usable Adaptive Educational e-
Content. 2002.
[SCHO89] U. Schoening. Logic for Computer Scientists. Birkhauser. EEUU.
1989.
[SER02] S. Krivov, Semantic Web and its Logical Foundations. Ecoinformatics
Collaboratory. Gund Institute. 2002.
[SEC04] G. Secundo, A. Corallo, G. Elia, G. Passiante. An e-Learning System
Based on Semantic Web Supporting a Learning in Doing Evironment.
International Conference on Information Technology Based Higher
Education and Training. Turqua. Junio 2004.
[SIE05] R.M. Siebes, pNear: combining Content Clustering and Distributed Hash
Tables.2nd. International Workshop on Peer to Peer Knowledge
Management. EEUU. Julio 2005.
[SIE06] R.M. Siebes, Semantic Routing in Peer-to-Peer Systems. Tesis doctoral.
Holanda. 2006.
[SIM06] S. Sim, R.I. Saiah. Relationship Between Item Difficulty and
Discrimination Indices in True/False-Type Multiple Choice Questions
of a Para-clinical Multidisciplinary Paper. Annals Academy of
Medicine. Febrero 2006.
[SOE96] A. Soeiro. The teaching Challenge of Open and Distance Learning.
EUCEN Journal Archive, 1996.
[STE04] K. Stege, T. Kelder, G. Huisman. Tutorial for Creating a BioPAX
Pathway with Jena. Technical University of Eindhoven. 2004.
[SWAP04] SWAP Final Report. Proyecto SWAP EU IST-2001-34103. Noviembre
2004.
[SWRL04] I. Horrocks et al. SWRL:A Semantic Web Rule Language Combining
OWL and RuleML. W3C Member Submission. Mayo 2004.
319
[TAL03] D. Talia, P. Trunfio. Towards a Synergy Between P2P and Grids. IEEE
Internet Computing, 2003 2003. 7(4). Pp: 94-96. 2003.
[TAL04] D. Talia, P. Trunfio. A P2P Grid Services-Based Protocol: Design and
Evaluation. EuroPar. 2004.
[TBL1998] Tim Berners-Lee. Semantic Web Road Map. W3C Design Issues.
Octubre 1998. URLhttp://www.w3. org/DesignIssues/Semantic.html.
[TBL2001] Berners-Lee, Hendler, Lassila. The Semantic Web. Scientific
American. Mayo 2001.
[TBL2001] T. Berners-Lee, J. Hendler, O. Lassila. The Semantic Web. Scientific
American. 2001.
[TELE01] Teleologic Learning Company. Objects, Vectors and Learning:
implications for SCORM. 2001.
[TIN97] L. Tinoco, E. Fox and N. Barnett, Online Evaluation in WWW-based
Courseware, The QUIZIT System, Proceedings of the 28th Annual
Symposium for Computer Based Education. Pp. 194-198. 1997.
[TOU05] R. Tous, J. Delgado. Using OWL for Querying an XML/RDF Syntax.
WWW2005. Japn. Mayo 2005.
[TRA03] B. Traversat, M. Abdelaziz, E. Pouyoul. Project JXTA: A Loosely-
Consistent DHT Rendezvous Walker. 2003.
[TRA03B] B. Traversat, M. Abdelaziz, E. Pouyoul. Project JXTA 2.0 Super-Peer
Virtual Network. 2003.
[TRO04] M. Trott, B. Trott. TrackBack 1.2 Technical Especificacion. 2004.
http://www.sixapart.com/pronet/docs/trackback_spec.
[TSA03] D. Tsarkov, I. Horrocks. DL Reasoner vs. First-Order Prover.
University of Manchester. 2003.
[TSA04] D. Tsarkov, I. Horrocks. Efficient reasoning with range and domain
constraints. 2004 Description Logic Workshop (DL 2004), vol 104. Pp:
41-50. 2004.
[TUR05] Z. Turk et al. Semantic Grid - Interoperability Solution for Construction
VO?. Proceedings of the International Conference on Information
Technology: Coding and Computing (ITCC05). EEUU. Abril 2005.
[ULL04] C. Ullrich. Description of an instructional ontology and its application in
web services for education SWEL Workshop 2004. Pp: 17-23. Japn.
2004.
[VER04] D.C. Verma. Legitimate Applications of Peer to Peer Networks. John
Wiley & Sons, Inc. 2004.
[WAG03] Gerd Wagner, Said Tabet, Harold Boley MOF-RuleML: The Abstract
Sytax of RuleML as a MOF Model. OMG Meeting. EEUU. Octubre
2003.
[WIL03] K. Wilkinson, C. Sayers, H. Kuno, D. Reynolds. Efficient RDF Storage
and Retrieval in Jena2 HP Techical Report. Diciembre 2003.
[WIL03] K. Wilkinson, C. Sayers, H. Kuno, D. Reynolds. Efficient Storage and
Retrieval of RDF Graphs in Jena2. First International Workshop on
Semantic Web and Databases. Alemania. Septiembre 2003.
320
Anexo 2. Referncias
[XIE03] M. Xie, P2P Systems Based on Distributed Hash Table. Septiembre

2003.
[YAN05] J. Yang, Q. Li, Y. Zhuang Multi-modal Information Retrieval with a
Semantic View Mechanism. Proceedings of the 19th International
Conference on Advanced Information Networking and Applications
(AINA05). China. Marzo 2005.
[ZHDA04] A.V. Zhdanova. Jena Tutorial. 2004.
[ZHO06] J. Zhou, J. Koivisto, E. Niemela. A Survey on Semantic Web Services
and a Case Study. Proceedings of the 10th International Conference on
Computer Supported Cooperative Work in Design. China. Mayo 2006.
[ZOU03] L. Zou. State and File Sharing in Peer to Peer Systems. Tesis doctoral.
Georgia Institue of Technology. Diciembre 2003.
Recursos en Internet
[WWW1] Pgina principal de la web semntica en W3C.
http://www.w3.org/2001/sw/
[WWW2] Pgina principal de RDF en W3c. http://www.w3c.org/rdf
[WWW3] http://www.ontoweb.org
[WWW4] http://www.cogsci.princetown.edu/ wn/
[WWW5] http://www-ksl-svc.standford.edu:5915
[WWW6] http://www.cyc.com
[WWW7] http://www.topicmaps.org
[WWW8] http://www.uml.org
[WWW9] http://citeseer.ist.psu.edu/
[WWW10] http://www.topicmaps.org/xtm
[WWW11] http://www.isotopicmaps.org
[WWW12] http://www.ruleml.org
[WWW13] http://www.sts.tu-harburg.de/~r.f.moeller/racer
[WWW14] http://www.daml.org/services/
[WWW15] IMS web page. http://www.imsglobal.org
[WWW16] http://web.mit.edu/oki
[WWW17] http://www.adlnet.org/
[WWW18] http://www.openuss.org
[WWW19] http://www.ist-universal.org
[WWW20] http://www.govtalk.gov.uk/schemasstandards/egif.asp
[WWW21] http://www.ariadne-eu.org
[WWW22] http://dublincore.org
[WWW23] http://ltsc.ieee.org/wg12/
[WWW30] Comparativa de distintas de finiciones de P2P.
http://www.anu.edu.au/people/Roger.Clarke/EC/P2POview.html#Defns
[WWW31] http://www.cachelogic.com
[WWW32] http://www.kazaa.com
[WWW33] http://www.coralcdn.org/
[WWW34] http://fedsearch.merlot.org
321
[WWW35] http://www.exlibrisgroup.com/
[WWW36] http://www.edna.edu.au/
[WWW37] http://www.merlot.org
[WWW38] http://edutella.jxta.org/
[WWW39] http://www.edusplash.net/
[WWW40] http://cordra.net
[WWW41] http://www.ubbcentral.com/
[WWW42] http://www.phpbb.com/
[WWW43] http://www.blabla4u.com/
[WWW44] http://www.fusetalk.com/
[WWW45] Comparativa de software para foros:
http://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software
[WWW46] http://java.sun.com
[WWW47] http://www.programacion.com/php/foros/
[WWW48] http://2ch.net/
[WWW49] Comparativa entre Pingback y Trackback. 2002, por el autor de
Pingback. http://ln.hixie.ch/?start=1033171507&count=1
[WWW50] SAKAI : Collaboration and Learning Environment for Education.
http://sakaiproject.org/.
[WWW51] Descripcin de Wiki. http://es.wikipedia.org/wiki/Wiki
[WWW52] Altova Semantic Works page.
http://www.altova.com/products/semanticworks/semantic_web_rdf_o
wl_editor.html
[WWW53] SWOOP page. http://www.mindswap.org/2004/SWOOP/
[WWW54] OWL consistency chequer, basado en Pellet.
http://www.mindswap.org/2003/pellet/demo.shtml.
[WWW55] Jena 2 Ontology API. http://jena.sourceforge.net/ontology/
[WWW56] B. McBride. Jena Tutorial.
http://jena.sourceforge.net/tutorial/index.html
[WWW57] Pgina principal de Jena. http://jena.sourceforge.net/
[WWW58] Informacin del proyecto wonderweb IST-2001-33052.
http://wonderweb.semanticweb.org/
[WWW59] Pgina principal de Pellet.
http://www.mindswap.org/2003/pellet/index.shtml
[WWW60] Informe de rendimientos de Pellet.
http://www.mindswap.org/2003/pellet/performance.shtml
[WWW61] RDF Query Survey. http://www.w3.org/2001/11/13-RDF-Query-
Rules/
[WWW62] SPARQL Query Language for RDF. W3C Recommendation
Candidate. http://www.w3.org/TR/rdf-sparql-query/
[WWW63] Proyecto OWL de la universidad de Standford (Standford Knowledge
Systems Laboratory). http://ksl.stanford.edu/projects/owl-ql/
[WWW64] Universal Decimal Classification. http://www.udcc.org/
[WWW65] Library of Congress Cataloging. http://www.loc.gov/catdir/
[WWW66] Pgina principal de Google. http://www.google.com
322
Anexo 2. Referncias
[WWW67] Pgina principal de Wikipedia. http:// www.wikipedia.org

[WWW68] W3C XML Signature Recommendation.
http://www.w3.org/TR/xmldsig-core/
[WWW69] Observatorio sobre estndares de tecnologas de la educacin.
http://www.cen-ltso.net/
[WWW70] Ejemplo de crtica a Web 2.0.
http://www.point-studios.com/archives/2005/10/web_20_buzzword.htm
[WWW71] Web de FaCT++. http://owl.man.ac.uk/factplusplus/
[WWW72] Pgina principal de blackboard. http://www.blackboard.com.
[WWW73] Foro de discusin de Prtg.
[email protected]
[WWW74] Foro de discusin de la web semntica.
[email protected]
[WWW75] Pgina principal de WebCT. http://www .webct.com
[WWW76] Pgina de W3C sobre XML. http://www.w3.org/XML/
[WWW77] Microsofts Repository Object Architecture.
http://msdn2.microsoft.com/en-us/library/aa179073(SQL.80).aspx
[WWW78] Pgina principal del proyecto de desarrollo Protg.
http://protege.stanford.edu.
323

Teleeducación WWW

Cargado por

Copyright:

Formatos disponibles

Teleeducación WWW

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

Teleeducación WWW

Cargado por

Copyright:

Formatos disponibles

DEPARTAMENTO DE COMUNICACIONES

ESPECIFICACIN OWL DE UNA

TESIS DOCTORAL PROPUESTA POR:

DIRIGIDA POR EL DOCTOR:

Con esa finalidad se desarrolla la Web Semntica, sistema que pretende

A ms, con el objetivo de aprovechar el potencial de la web, se han ido

El presente trabajo pretende potenciar esta interoperabilidad de objetos

La ontologa presentada va adems acompaada de una especificacin de

Amb esta finalitat es desenvolupa la Web Semntica, sistema que pretn

A ms, amb lobjectiu daprofitar el potencial de la web, shan anat generant

El present treball pretn potenciar esta interoperabilitat dels objectes

Lontologia presentada va tamb acompanyada duna especificaci

The document presented fosters this LOs interopeability. To achieve this

A new architecture called Semantic DHT is defined in order to exploit the

En primer lugar a mi director de tesis D. Carlos Enrique Palau Salvador, por

A D. Patricio Montesinos Sanchis y D. Mnica Lpez Sieben, director y

Deseo agradecer a gigantes de la comunidad cientfico-tcnica que slo

Finalmente a mi familia, por haber estado en todo momento animndome a

ESPECIFICACIN OWL DE UNA

TESIS DOCTORAL PROPUESTA POR:

DIRIGIDA POR EL DOCTOR:

Captulo 1: Introduccin .......................................................................... 1

2.3.5 Ontologas en Teleeducacin ............................................... 43

3.3.5.3 Constructores y axiomas en OWL ................................ 100

5.5.3 Elementos del sistema........................................................ 174

7.4 Sistema de bsquedas e inferencias ........................................... 271

Las tendencias actuales en Teleeducacin se centran en la reutilizacin de

calidad desde cero frente a la reutilizacin de contenidos de calidad

Adems, para conseguir dicha re-usabilidad se han de generar mecanismos

Entendemos como Agente Inteligente [RUS96] a toda entidad que percibe y

Un Agente Inteligente desarrolla, en mayor o menor medida, las siguientes

entorno. Para conseguirlo se basa en otras caractersticas como la

La definicin de Agente Inteligente no indica el grado de inteligencia que

En los sistemas de bsqueda actuales, se ha generalizado la tendencia a

Sin embargo, ahora se est empezando a probar seriamente la introduccin

En estos ltimos aos se est afianzando el lenguaje de descripcin de

Por otra parte, otra tendencia detectada en las herramientas de

Es decir, las nuevas tendencias de Teleeducacin dan ms importancia a

1.2 Motivacin de la Tesis

Despus, en una segunda fase, basndose en la experiencia y viendo lo

aparece la necesidad de marcar los objetos educativos por medio de

Pero ahora se plantea la necesidad de agentes de bsqueda ms inteligentes

Por tanto, lo que nos motiva a la realizacin de dicha Tesis es contribuir al

Los objetivos generales de esta Tesis son:

Estudiar y aplicar las nuevas tendencias en interoperabilidad de

Incluir en la descripcin de los objetos educativos las

Contribuir al desarrollo y mejora de los sistemas de

Impulsar el uso de la Web Semntica en Teleeducacin. Este

Estudiar las posibilidades de agentes inteligentes en la

Siendo los objetivos especficos los siguientes:

Mostrar el estado del arte en la Teleeducacin basado en la Web

Estudiar las ontologas educativas existentes ms importantes.

Describir las interacciones ms importantes que se producen en

Definir, desarrollar y evaluar una ontologa para educacin que

Expresar dicha ontologa en OWL, de forma que pueda ser

Proponer y definir una arquitectura para la web semntica en

Definir, desarrollar y evaluar un prototipo de agente de

1.4 Principales aportaciones

Primeras integraciones de las interacciones de los actores de una