2010-12-10 (uc3m) eMadrid jcvidal usc integracion de ims ld en mundos virtuales
1. Integración de IMS LD en
mundos virtuales
Juan Carlos Vidal Aguiar
Universidad de Santiago de Compostela
Red eMadrid, www.emadridnet.org
Universidad Carlos III de Madrid (Madrid), 10 de Diciembre de 2010
2. Mundos virtuales 3D
Metaversos o mundos virtuales 3D son entornos gráficos
tridimensionales, multiusuarios, inmersivos e interactivos
generados por computadoras en tiempo real
3. Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Corporeidad
• El mundo virtual se compone
de elementos físicos 3D cuya
dinámica está gobernada por
leyes físicas del mundo real
• Los usuarios se identifican con
un avatar que es su alter ego
en el mundo virtual 3D
• Cualquier acción que toma el usuario como siempre tiene lugar a través del
avatar con el que se identifica el usuario
4. Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Interactividad
• Los avatares interaccionan con el mundo
virtual para obtener/generar información o para
modificar los elementos de los que se compone
• Los avatares interaccionan con los otros
avatares del mundo virtual para socializar
(como sucede en el mundo real)
• Uso de herramientas de comunicación
para facilitar la interacción entre los usuarios
(chat, audioconferencia, …)
5. Principales características
Las principales características de los mundos virtuales 3D
son la corporeidad, la interactividad, y la persistencia
Persistencia
• El mundo virtual 3D sigue
evolucionando independientemente de
que el usuario esté o no esté conectado
• El estado del avatar se mantiene
entre sesiones consecutivas; es decir,
se recuerda el resultado de las
acciones realizadas por el avatar
• Esta característica es un reflejo de lo que sucede en el mundo real:
el entorno del avatar puede evolucionar aún cuando no esté presente
6. Entornos docentes virtuales 3D
Las características de los mundos virtuales 3D son muy
deseables cuando se aplican a la Educación en los
llamados entornos docentes virtuales 3D
Favorecen la inmersión de los estudiantes en el entorno docente
3D virtual, lo que aumenta su nivel de implicación en la
realización de las actividades docentes
Favorecen la interacción y comunicación entre todos los que
participan en las actividades de aprendizaje
(estudiante estudiante, estudiantes profesor)
Permiten una gran variedad de estilos de aprendizaje, y en
especial favorecen el aprendizaje colaborativo
7. Entornos docentes virtuales 3D
Pizarra Virtual Mundo virtual 3D
Interacción Los usuarios expresan sus ideas Los usuarios expresan sus ideas
de modo colaborativo en la de forma colaborativa en un
pizarra virtual de forma elemento físico del entorno
colaborativa docente
Persistencia El contenido de la pizarra El contenido de la pizarra
virtual cambia entre cambia entre conexiones
conexiones consecutivas del consecutivas del usuario
usuario
Corporeidad Los usuarios de una pizarra Los avatares y el entorno
virtual no son corpóreos docente dan la sensación de
corporeidad y de inmersión en
el entorno virtual
8. Entornos docentes virtuales 3D
En los últimos años empresas y universidades han
desarrollado un buen número de entornos docentes
virtuales 3D
Se crean sofisticados y muy elaborados campus de docencia para
aumentar la sensación de inmersión en el mundo virtual por parte
de los estudiantes
Campus virtual en 3D en el que
se incluyen elementos físicos
paisajísticos
9. Entornos docentes virtuales 3D
Aulas docentes con proyectores y pizarras
virtuales
Salas de socialización
Edificios administrativos y bibliotecas
La mera réplica de campus reales a campus virtuales 3D no es
suficiente para mejorar el aprendizaje: es necesario aplicar técnicas
docentes basadas en las interacciones y la colaboración entre
estudiantes
10. ¿Cómo aplicar las técnicas
docentes en los mundos virtuales?
Existe muy poca investigación y experimentación en este punto:
La mayoría de propuestas centradas en el ámbito de los juegos
(ejemplo: <e-Adventure>)
Arquitectura software no es lo suficientemente flexible como para
generalizar la solución a otras plataformas
Las soluciones son fuertemente dependientes del entorno docente
virtual 3D que se ha definido
11. Plataformas de mundos virtuales
Se han desarrollado una serie de plataformas de mundos virtuales de
propósito general:
Opensim Open Wonderland
Second Life Open Cobalt
De las cuales Opensim y Second Life han sido de largo las más usadas
en el ámbito educativo.
12. Plataformas de mundos virtuales
Second Life Opensim
Lenguaje de LSL (Linden Script Language) LSL + extensiones
scripts
Código No Sí
abierto (propiedad de Linden Labs)
Lenguaje de C# C#
desarrollo (permite añadir nuevos módulos
en C# y en Php)
Second Life y Opensim utilizan LSL como el lenguaje de scripts con el
que se da tratamiento a los eventos que los avatares generan en el
mundo virtual.
13. ¿Por qué no aprovechar los
cursos ya creados?
Un Lenguaje de Modelado Educativo (EML) describe el flujo de
actividades de aprendizaje a realizar por los estudiantes y profesores,
con el fin de alcanzar unos objetivos educativos, y utilizando el material
educativo proporcionado.
14. Aprendizaje adaptativo NUESTRA
ELECCIÓN
IMS Learning Design (IMS LD)
ha surgido como el estándar de
facto dentro de los EML debido
a su alto nivel de consenso y su
soporte tecnológico
Define un esquema de control complejo.
Utiliza el formato XML Schema para especificar las unidades de aprendizaje.
Es necesario un intérprete para automatizar la ejecución de los flujos de trabajo
de IMS LD.
En nuestro desarrollo utilizamos OPENET4LD, un motor de flujos de trabajo que
implementa las unidades de aprendizaje IMS LD.
15. E-learning
Colaboración + aprendizaje
Educación + entorno social
Digital media that enable socialization + aprendizaje
EML / IMS-LD EDUCACIÓN +
+ INTERNET MUNDOS 3D
No existe un motor de
Herramientas de ejecución para desarrollar
comunicación y soportar el curso
Síncrona: chat
Por ejemplo:
EML / IMS-LD + Moodle + Second Life,
Asíncrona: correo,
foros, etc.
MUNDOS 3D enfocados a los contenidos
y no en la ejecución
16. Primera opción de integración
El control de definido en IMS LD se diseña/replica
directamente en la plataforma de metaversos
El control está distribuido entre los elementos físicos del escenario
y programado con el lenguaje de scripting, específico de cada
plataforma de metaversos.
Problemas:
El lenguaje de scripting debe soportar la definición de
estructuras de datos complejas.
El motor tiene una fuerte dependencia con el escenario virtual
educativo.
17. Segunda opción de integración
El motor IMS LD se implementa como un
módulo software de la plataforma de metaversos
Problemas:
El motor depende de la implementación de la plataforma de
metaversos, sus interfaces y sus componentes software.
Esta solución es válida sólo para Opensim, ya que esta
plataforma tiene una arquitectura abierta y extensible a través
de pluggins.
18. Tercera opción de integración
NUESTRA
ELECCIÓN
Integración basada en las comunicaciones:
El motor IMS LD está fuera de la plataforma de metaversos
Beneficios:
Se simplifica el diseño de los scripts que quedan reducidos a
llamadas al motor IMS LD.
La solución es más portable a otras plataformas. El flujo de trabajo
definido en el motor IMS LD no cambia, de forma que únicamente se
necesitaría (re)implementar los scripts.
Se utiliza el protocolo HTTP y RPC para comunicarse con el motor,
el cual devuelve los resultados como cadenas de texto (URL,
identificadores de actividades, etc.).
19. Marco conceptual de integración
Identificar los elementos de los que se componen los
entornos docentes virtuales 3D que intervienen en la
ejecución de unidades de aprendizaje IMS LD
Componentes físicos del entorno docente virtual 3D
Avatares que juegan los roles de
estudiantes y de profesores
Scripts que gestionan los eventos generados en el
mundo virtual 3D
Motor IMS LD que gestiona la correcta ejecución de
la unidad de aprendizaje adaptativa
20. Marco conceptual de integración
Los elementos físicos del Los scripts invocan a los
entorno docente tienen servicios del motor de
ligados scripts cuya ejecución encargados de
invocación tiene ante la realizar la adaptación de
ocurrencia de un evento la unidad de aprendizaje
El avatar interacciona Los avatares no tienen
con los elementos físicos interacción directa con
del entorno virtual el motor IMS LD: debe
generando eventos que establecerse a través de
deberán ser tratados por un elemento físico 3D
el sistema
21. ¿Cómo se integran los mundos
virtuales con los motores IMS LD?
Nuestra solución implica el diseño de una
arquitectura distribuida de cara a facilitar el acceso
de la plataforma de metaversos a las funcionalidades
del motor IMS LD.
Analizamos dos opciones:
Arquitectura basada en agentes.
Arquitectura orientada a servicios.
22. ¿Arquitectura orientada a
servicios? NUESTRA
ELECCIÓN
Las funcionalidades del motor están externalizadas
a través de servicios web y proporcionan acceso:
Al estado y ejecución de los flujos de trabajo IMS LD.
A los contenidos y recursos educativos de las unidades de aprendizaje.
Beneficios:
Permite la reutilización de la arquitectura en otras plataformas de
metaverso.
Adición de nuevas funcionalidades sin cambiar los scripts ni los
servicios.
23. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC
(MRM) Management Publication
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
24. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
La capa cliente se
encarga System ejecutar Server 9.1
Sun Java de Application Web Services
los scripts invocados
por las accionesBPEL SE
HTTP BC de los UoL2FLORA
UoL
Validation
clientes
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC
(MRM) Management Publication
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
25. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
La capa servidorUoLState
dispone
PNDefinition
JDBC BC
Metaverse
de un módulo para la
Management
Requests invocación de servicios
Management User UoL
MQ BC
(MRM) disparados
Management por
Publication los
scripts de la plataforma
SMTP BC
de metaversos.
UDDI BC JBI Runtime
Environment OPENET4LD
26. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
La capa de servicios UoLState
PNDefinition
publica las funcionalidades
JDBC BC Management
Metaverse
del motor y resuelve las
Requests
Management User UoL
MQconsultas a las unidades
BC
(MRM) Management Publication
de aprendizaje.
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
27. Escenario docente
Pantalla
Facilita la visualización del
contenido educativo (como
vídeos o presentaciones)
asociado a las actividades de
las unidades de aprendizaje
que están ejecutando en ese
momento.
Panel de selección
Facilita la interacción de los avatares con el motor IMS LD, de forma
que pueden buscar información acerca de una determinada unidad
de aprendizaje y obtener la(s) siguiente(s) actividad(es) a realizar.
28. Pantalla y modos de operación
1. Todos los avatares visualizan
el mismo contenido.
Los profesores aplican esta
estrategia para explicar el
contenido a los alumnos.
2. El avatar visualiza el contenido de forma individual.
Los estudiantes usan la pantalla para desplegar los recursos
educativos asociados a la actividad que están realizando.
29. Panel de selección
Cuando el avatar
toca esta parte del Cuando el avatar toca
panel, se invoca el esta parte del panel,
servicio web se invoca el servicio
encargado de web encargado de
obtener los obtener la información
recursos asociados y objetivos de la
con la unidad de actividad que está
aprendizaje. realizando.
Cuando el avatar En panel de notas
toca esta parte del (notecard) muestra
panel, se invoca el la información
servicio web que relativa a la actual
finaliza la actividad unidad de
actual. Como aprendizaje.
resultado, se
muestra al avatar la
siguiente actividad a
realizar.
31. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC
(MRM) Management Publication
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
32. Gestión de peticiones del servidor
Sun Java System Application Server 9.1 Un Servidor de Aplicaciones da
soporte al despliegue e invocación
HTTP BC BPEL SE
de los servicios Web.
XSLT SE
JMS BC
Módulo de gestión de peticiones de
File BC
SQL SE
JAXWS
los metaversos (Metaverse Requests
Management - MRM):
MMR (JBI Bus)
IEP SE
FTP BC
JDBC BC Se compone de un conjunto de servlets
Metaverse
Requests
Management
MQ BC
(MRM) Los servlets recogen directamente las
SMTP BC
peticiones de los scripts (a través de la
función HTTPRequest, y ejecutan el
UDDI BC JBI Runtime
Environment método GET como consecuencia de
esas peticiones) y redirige las
BC: Binding Component peticiones al correspondiente servicio
SE: Service Engine
web del motor IMS LD
33. Gestión de peticiones del servidor
Sun Java System Application Server 9.1 Un Servidor de Aplicaciones da
soporte al despliegue e invocación
HTTP BC BPEL SE
de los servicios Web.
XSLT SE
JMS BC
Módulo de gestión de peticiones de
File BC
SQL SE
los metaversos (Metaverse Requests
La necesidad de este módulo está
JAXWS
Management - MRM):
MMR (JBI Bus)
FTP BC
impuesta por las limitaciones del lenguaje
IEP SE
de scripts.
JDBC BC Se compone de un conjunto de servlets
Metaverse
Requests
Management
MQ BC
(MRM) Los servlets recogen directamente las
SMTP BC
peticiones de los scripts (a través de la
función HTTPRequest, y ejecutan el
UDDI BC JBI Runtime
Environment método GET como consecuencia de
esas peticiones) y redirige las
BC: Binding Component peticiones al correspondiente servicio
SE: Service Engine
web del motor IMS LD
34. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC
(MRM) Management Publication
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
35. Arquitectura del motor IMS LD
IMS LD Engine
Base de conocimiento
OPENET Engine
Schema Schema Schema Schema
HLPN MAPPINGS HHLPN MAPPINGS OPENET MAPPINGS IMS LD
Ontology Ontology Ontology Ontology
Data Data Data Data
HLPN MAPPINGS HHLPN MAPPINGS OPENET MAPPINGS IMS LD
Instances Instances Instances Instances
Rules Rules Rules Rules
HLPN HHLPN OPENET IMS LD
Reasoning Reasoning Reasoning Reasoning
FLORA-2 Reasoner
Inference Engine
Reasoner Interface
HLPN engine interface HHLPN engine interface OPENET engine interface IMS LD engine interface
36. Arquitectura del motor IMS LD
IMS LD Engine
Base de conocimiento
OPENET Engine
Schema Schema Schema Schema
HLPN MAPPINGS HHLPN MAPPINGS OPENET MAPPINGS IMS LD
Ontology Ontology Ontology Ontology
Data Data Data Data
HLPN MAPPINGS HHLPN MAPPINGS OPENET MAPPINGS IMS LD
Instances Instances Instances Estas tres capas
Instances
Rules Rules Rules definen Rules
la semántica
HLPN HHLPN OPENET IMS LD
Reasoning Reasoning Reasoning de ejecución de los
Reasoning
flujos de trabajo. Esta
FLORA-2 Reasoner
Inference Engine
ejecución se basa en
el formalismo de las
Reasoner Interface redes de Petri.
HLPN engine interface HHLPN engine interface OPENET engine interface IMS LD engine interface
37. Arquitectura del motor IMS LD
IMS LD Engine
Base de conocimiento
OPENET Engine
Schema Schema Schema Schema
HLPN MAPPINGS HHLPN MAPPINGS OPENET MAPPINGS IMS LD
Ontology Ontology Ontology Ontology
Data
Esta capa contiene la Data
Data Data
HLPN
Instances
MAPPINGS ontología de IMS LD yInstances
HHLPN
Instances
MAPPINGS el
OPENET MAPPINGS IMS LD
Instances
conjunto de
Rules Rules Rules Rules
HLPN transformaciones queOPENET
HHLPN IMS LD
Reasoning Reasoning Reasoning Reasoning
permiten definir un flujo de
trabajo a partir del modelo
FLORA-2 Reasoner
IMS LD. Inference Engine
Reasoner Interface
HLPN engine interface HHLPN engine interface OPENET engine interface IMS LD engine interface
38. Arquitectura orientada a servicios
CAPA CLIENTE CAPA SERVIDOR CAPA DE SERVICIOS
Sun Java System Application Server 9.1 Web Services
HTTP BC BPEL SE UoL
UoL2FLORA
Validation
XSLT SE
OpenSim/Second Life Viewer
OpenSim/Second Life Server
JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
IEP SE Management Execution
FTP BC
UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC
(MRM) Management Publication
SMTP BC
UDDI BC JBI Runtime
Environment OPENET4LD
39. Servicios web del motor IMS LD SERVICE LAYER
Esta capa se compone de un Web Services
conjunto de servicios que UoL2FLORA
UoL
externalizan las funcionalidades del Validation
motor de IMS LD: PN
IMSLD2PN
Execution
Publicar una UoL en el motor PNState
Management
UoL
Execution
Validar la estructura de una UoL PNDefinition
UoLState
Management
Iniciar la ejecución de una UoL User
Management
UoL
Publication
Gestionar los roles
OPENET4LD
Gestionar los usuarios
40. Servicios web del motor IMS LD
Más funcionalidades: SUSPENDED UNSTARTED
Gestionar la ejecución de una suspend
UoL
enable
resume
selection
run
hierarchical
Parar, suspender o reanudar la PAUSED
resume
RUNNING
run
SELECTED
select
SELECTABLE
ejecución de un método, play, hierarchical
suspension
acto o actividad show selected activity
is finished
Realizar una actividad
finish / stop / halt/timeout /
when-property-value-is-set another activity
hide is selected
DISABLED
Acceder al estado de una
ejecución FINISHED
41. Servicios web del motor IMS LD
Otras funcionalidades:
Transformar una UoL
a red de Petri
…
Los servicios están
descritos en WSDL y se
invocan a través de
mensajes SOAP.
42. Conclusiones
Las características de los mundos virtuales 3D son muy
deseables cuando se aplican a la Educación en los
llamados entornos docentes virtuales 3D:
Favorecen la inmersión de los estudiantes en el entorno docente
3D virtual, lo que aumenta su nivel de implicación en la
realización de las actividades docentes
Favorecen la interacción y comunicación entre todos los que
participan en las actividades de aprendizaje
(estudiante estudiante, estudiantes profesor)
Permiten una gran variedad de estilos de aprendizaje, y en
especial favorecen el aprendizaje colaborativo
43. Conclusiones
Hemos visto como a través de una arquitectura orientada a servicios
se facilita la ejecución, desde una plataforma de metaversos, de UoLs
basadas en el estándar IMS LD.
En esta arquitectura externaliza las funcionalidades del motor IMS LD
a través de servicios web de forma que terceras aplicaciones puedan
controlar la ejecución de las UoLs y los recursos educativos.
Las principales ventajas de esta aproximación son:
Reutilización de cursos previamente especificados en IMS LD
Reducir la complejidad de los scripts
La solución es “fácilmente” aplicable a otras plataformas de metaversos
44. Trabajos futuros
Mejorar el marco de integración en dos puntos:
Integrar más elementos físicos al entorno docente.
Reducir la complejidad del módulo usado para la gestión
de las peticiones desde la plataforma de metaversos.
Para ello se planeamos introducir la ejecución de estos
servicios web a través del lenguaje BPEL.