2010-12-10 (uc3m) eMadrid jcvidal usc integracion de ims ld en mundos virtuales

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

Mundos virtuales 3D
Metaversos o mundos virtuales 3D son entornos gráficos
tridimensionales, multiusuarios, inmersivos e interactivos
generados por computadoras en tiempo real

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

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, …)

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

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


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

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

 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

¿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

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.

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.

¿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.

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.

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

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.

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.

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.).

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

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

¿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.

¿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.

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

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


JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
FTP BC

UoLState
PNDefinition
JDBC BC Management
Metaverse
Requests
Management User UoL
MQ BC

SMTP BC

UDDI BC JBI Runtime



HTTP BC BPEL SE UoL
UoL2FLORA
Validation

XSLT SE


JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
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



HTTP BC BPEL SE UoL
UoL2FLORA
Validation

XSLT SE


JMS BC PN
IMSLD2PN
Execution
SQL SE
File BC
JAXWS
PNState UoL
MMR (JBI Bus)
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
de aprendizaje.
SMTP BC

UDDI BC JBI Runtime

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.

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.

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.

Capa cliente: scripts

1. Vídeos

2. Imágenes

3. Presentaciones

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

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

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

IMS LD Engine
OPENET Engine

Data Data Data Data
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.


IMS LD Engine
OPENET Engine

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


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

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

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.

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

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

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.

2010-12-10 (uc3m) eMadrid jcvidal usc integracion de ims ld en mundos virtuales

Más contenido relacionado

La actualidad más candente (17)

Similar a 2010-12-10 (uc3m) eMadrid jcvidal usc integracion de ims ld en mundos virtuales (20)

Más de eMadrid network (20)

Último (20)

2010-12-10 (uc3m) eMadrid jcvidal usc integracion de ims ld en mundos virtuales