tema2encontrar un recurso educativo. los metadatos

Encontrar un recurso educativo. Los metadatos

[2.1] ¿Cómo estudiar este tema?

[2.2] Introducción

[2.3] IEEE Learning Object Metadata (LOM)

[2.4] Dublin Core (DC)

[2.5] Los perfiles de aplicación. Variaciones sobre LOM y DC

T

EM

A

Especificaciones y estándares sobre elearning y TIC

TEMA 2 – Esquema

Esquema

Met

adat

os

Gen

eral

Du

bli

nC

ore

Tec

hn

ical

Lif

eC

ircl

e

Ed

uca

tion

al

LO

M-E

S

DC

-Ed

Can

core

LO

MP

erf

ile

s a

pli

caci

ón

Met

a-m

etad

ata

Rig

ht

Cla

ssif

icat

ion

Rel

atio

n

An

not

atio

n

Con

ten

ido

Pro

pied

ad in

tele

ctua

l

Inst

alac

ión


TEMA 2 – Ideas clave

Ideas clave

2.1. ¿Cómo estudiar este tema?

En este tema se realiza una primera aproximación a los metadatos para la descripción

de recursos educativos. Se recomienda realizar una primera lectura y a continuación

leer los documentos incluidos en la sección Lo + Recomendado. Existe una versión

de la especificación LOM en castellano, lo cual facilitará la lectura de esta.

Dado que Dublin Core es una propuesta mucho más sencilla que LOM, se recomienda

comenzar por profundizar en la comprensión de esta. Una vez que el alumno se sienta

seguro en su uso puede pasar a estudiar en detalle el estándar LOM.

En el caso de los perfiles de aplicación, se pretende únicamente que el alumno

comprenda su utilidad, para qué sirven. No es necesario profundizar en ninguno de los

perfiles presentados, aunque sí se recomienda una lectura de alguno de los múltiples

perfiles existentes, por ejemplo de LOM, una vez que se comprenda el significado de

sus categorías y elementos.

Una segunda lectura de este tema facilitará la contestación de las preguntas del test y la

elaboración de la actividad propuesta. En esta actividad se pretende que el alumno

realice una descripción parcial de un objeto educativo utilizando el estándar LOM. Para

su realización se recomienda tener a mano y consultar todas las veces que sea necesario

la norma LOM, bien en su versión original en inglés o en la disponible en castellano.

2.2. Introducción

La definición de metadatos para recursos educativos es uno de los campos más

prolíficos en el proceso de estandarización de elearning. En su definición más simple,

metadatos son datos sobre datos, descripciones, propiedades, informaciones de

objetos que los caracterizan para facilitar su manejo y gestión. En el caso que nos ocupa

se tratará de metadatos sobre recursos educativos. Por recurso educativo consideramos

una entidad que puede ser utilizada o referida durante un proceso de aprendizaje.



La necesidad de utilizar metadatos se debe al crecimiento de la

cantidad de documentos y recursos educativos. La falta de

información, o lo que llamamos metadatos, sobre esos recursos

limitaría nuestras posibilidades para descubrirlos, gestionarlos y

utilizarlos. Los metadatos nos permiten realizar estas operaciones

de una forma estándar y eficiente, al recoger en unas pocas

propiedades, total y perfectamente caracterizadas, las informaciones que más nos

interesan de los recursos.

Para entender la necesidad de los metadatos podemos hacer una analogía con una

biblioteca. En una biblioteca se dispone generalmente de una cantidad muy grande de

documentos. Se tienen multitud de libros, revistas, enciclopedias, etc. de forma que

sería muy difícil realizar una búsqueda de un título en concreto si no se dispusiese de

una organización adecuada. Por eso, realiza una tarea de clasificación previa, creando

un fichero con información sobre cada título, del que se guardan unos pocos datos:

autor, título, materia, año de publicación, etc. esto es, metadatos. Posteriormente, si

queremos realizar una búsqueda utilizamos este fichero y buscamos en las fichas por

alguno de los metadatos que nos interesan. En Internet tenemos el mismo problema y

recurrimos a la misma técnica de utilización de metadatos para clasificarlos,

organizarlos y finalmente buscarlos de forma automática.

Además, con los metadatos adecuados no solo será posible automatizar la búsqueda,

sino también mejorar la utilización de los recursos en general. Se facilitarán las tareas

de compartir e intercambiar cursos y contenidos entre distintos sistemas educativos. Se

permitirá a agentes software la construcción automatizada de los contenidos que se les

presentarán a los estudiantes de forma individualizada, etc.

En este tema se presentan dos de las propuestas más relevantes sobre metadatos para

recursos educativos:

1. En primer lugar el estándar propuesto por el IEEE LTSC: Learning Object

Metadata (LOM) que puede considerarse como el estándar de factor en este

ámbito.

2. Se presenta a continuación la propuesta Dublin Core (DC), de gran relevancia en

otros ámbitos, por ejemplo, las bibliotecas y que también ha sido utilizado con

profusión para la descripción de contenidos educativos. Durante la última década

han sido estas dos las alternativas más utilizadas para la descripción de contenidos

educativos.



El alumno podrá valorar, después de estudiar este tema cuáles son las ventajas de una

propuesta sobre otra. Finalmente se realiza una introducción a los perfiles de

aplicación, variaciones sobre estas especificaciones y estándares base, que se adaptan

a necesidades o realidades concretas en un ámbito de conocimiento (por ejemplo

ingeniería), nivel educativo (por ejemplo, enseñanza primaria) o contexto educativo

(por ejemplo el sistema educativo español).

Las propuestas que se presentan en este tema no son las únicas existentes, aunque si

podemos decir que las más relevantes y las que han servido de base para la generación

del resto. Se han incluido varias referencias a otras propuestas. Dentro de estas es de

especial importancia el estándar que recientemente ha publicado la ISO para

metadatos: Metadata for Learning Resources (MLR).

Alguna referencia se ha incluido en el apartado Lo + Recomendado y se sugiere al

alumno que se tome su tiempo en analizar también esta nueva propuesta que puede

tener un protagonismo muy importante en los próximos años.

2.3. IEEE Learning Object Metadata (LOM)

Uno de los principales contribuidores al proceso de definición de metadatos para

recursos educativos es el IEEE, a través de su grupo de trabajo P1484.12 de metadatos

para recursos educativos, el cual ha definido LOM, Learning Object Metadata.

LOM se ha convertido en referencia para la comunidad en el campo de la descripción

de recursos educativos, aunque hay que decir que su creación no se debe solamente al

IEEE. Entre las aportaciones más importantes destacan las realizadas por el consorcio

IMS y el proyecto ARIADNE.

LOM especifica la sintaxis y semántica de metadatos para objetos educativos. Su

propósito es buscar la especificación más pequeña posible, pero que a la vez resulte útil,

factible, viable técnica y comercialmente, de uso generalizado y que admita la

incorporación de extensiones. En la especificación se incluyen características como el

nombre de los elementos, definiciones, tipos de datos y longitudes de los campos. Se

dispone, además, de enunciados de conformidad en los que explican cómo deben ser

los documentos de metadatos y las aplicaciones para ser consideradas conformes

con LOM.



La información de LOM puede utilizarse para los siguientes propósitos:

mantenimiento de estabilidad de versiones, almacenamiento (asociando los

registros LOM con el recurso educativo o incorporándola de forma directa en el

mismo), recuperación de información (esto incluye los procesos de buscar, ubicar,

iniciar, empaquetar, editar, etc.) e intercambio de datos entre aplicaciones. En

cualquier caso, los desarrolladores de LOM indican que puede utilizarse para

propósitos que no se recogen en su especificación como son la gestión de los derechos

de la propiedad intelectual o el comercio electrónico.

Conformidad con LOM

En LOM todos los elementos son opcionales. Se establece que un registro de metadatos

es conforme con LOM si satisface los cuatro requisitos siguientes:

1. Contiene uno o más elementos LOM.

2. Todos los elementos de LOM en el registro de metadatos se utilizan para describir

características definidas por la especificación (ejemplo: no se debe utilizar el

elemento Title para describir las fuentes utilizadas en el documento).

3. Los valores de los elementos de los registros estarán estructurados según la

definición de la especificación LOM, y esta estructura debe mantenerse en la

instancia. Debe mantenerse la agrupación en categorías y subelementos, pero los

autores de los registros pueden definir correspondencias de esta estructura a la que

ellos utilicen.

4. Si la instancia contiene extensiones, estas no pueden reemplazar elementos de la

estructura de LOM.

Se dice que una implementación de LOM es estrictamente conforme con la

especificación si no realiza extensiones a esta.

En cuanto a las aplicaciones, para que sean conformes con LOM deben satisfacer los

siguientes requisitos:

Una aplicación conforme debe ser capaz de procesar al menos un metadato LOM.

Si la aplicación recibe una instancia de metadatos conforme con LOM, la almacena y

después la transmite, entonces, la aplicación preserva la instancia original de

metadatos durante la retransmisión.



En cuanto a la funcionalidad, una aplicación conforme debe realizar al menos una de

las cuatro funciones siguientes:

Representar información para catalogar contenidos educativos.

Buscar o catalogar contenidos educativos.

Describir contenidos educativos.

Iniciar contenidos educativos.

Estructura básica de LOM

Dado que las propiedades a describir son heterogéneas, los elementos que constituyen

la descripción de metadatos se dividen en grupos. En concreto en el caso de LOM se

han identificado nueve categorías diferentes en las que se agrupan los 60

metadatos que define.

Para realizar la especificación de los metadatos utilizan el estándar ISO/IEC 114041. En

las cadenas de caracteres, characterstring, los caracteres que se pueden introducir son

los definidos en la norma ISO/IEC 10646-1. Se utilizan tres estructuras de datos

especiales:

1. LangString. Es una estructura que permite introducir un texto en distintos

idiomas. Se requiere una lista de al menos diez elementos formados por una cadena

de caracteres y por un identificador, que se utiliza para indicar el idioma en el que se

expresa el contenido de la cadena. El idioma es una cadena de caracteres de al

menos 100 caracteres. Esta estructura se puede utilizar, por ejemplo, para indicar

cuál es el título de un recurso en distintos idiomas.

2. Date. Se utiliza para indicar una fecha.

3. Vocabulary. Es una lista de valores recomendados para los elementos, si bien,

también se pueden emplear valores no especificados en la lista como valores de los

elementos. Está definido por dos campos: un campo fuente (source) de tipo

LangString con una longitud mínima de 1000 caracteres; un campo valor (value) de

tipo LangString con una longitud mínima de 1000 caracteres.

1 Especificación para la definición de tipos de datos de forma independiente al lenguaje de

programación.



A continuación se recogen los metadatos de LOM. Además de su denominación en

castellano se indica la terminología inglesa original, dado que en la mayoría de los

trabajos realizados es la que se utiliza.

General

Ciclo de vida

Meta-metainformación

Uso educativo

Metadatos de LOM

1

2

3

5

Derechos6

Relación7

Observaciones8

Clasificación9

Técnica4

General (General)

Agrupa todas las características independientes del contexto junto con las

descripciones semánticas del objeto educativo (learning object). En esta categoría se

recogen los siguientes elementos:

o Identificador (Identifier). Es un identificador único para el objeto educativo.

Puede ser transparente para el creador de los metadatos, siendo introducido por

el sistema que los gestiona. Este campo está identificado como reservado

(Reserved) y no lleva asociado ningún tipo de datos.

o Título (Title). Nombre que recibe el objeto educativo. El tipo de datos que se

debe proporcionar es un LangString con una capacidad de al menos 1000

caracteres.

o Entrada de catálogo (CatalogEntry). Designación dada al objeto educativo.

Es un registro formado por dos elementos. Una de las entradas en el catálogo

puede ser generada automáticamente por la herramienta que se utiliza para crear

los metadatos. Se debe permitir introducir al menos diez entradas diferentes.



Catálogo (Catalog). Indicación de la fuente de catalogación que se utiliza (por

ejemplo: "ISBN", "ARIADNE"). Normalmente será generada por la

herramienta que se utilice para introducir los metadatos. El tipo de datos es

una cadena de caracteres con una capacidad de al menos 1000 caracteres.

Entrada (Entry). La asignación recibida según la catalogación aplicada (por

ejemplo: "2-7342-0318", "LEA0875"). El tipo de datos es LangString con una

capacidad de al menos 1000 caracteres.

o Idioma (Language). El idioma principal utilizado en este recurso. Se utilizan

valores construidos combinando un código del idioma, definido según la norma

ISO639 y, opcionalmente, un código del país, según ISO3166 ("en", "en-GB"). El

tipo de datos es una cadena de caracteres con una capacidad de al menos 100

caracteres. Se deben permitir introducir al menos diez idiomas diferentes para un

mismo documento.

o Descripción (Description). Descripción textual del contenido del recurso. El

tipo de datos que se debe proporcionar es un LangString con una capacidad de al

menos 2000 caracteres. Se deben permitir al menos diez descripciones

diferentes.

o Descriptor (Keywords). Las palabras clave que describen el objeto educativo.

Recomiendan no utilizarlo para características que pueden ser descritas a través

de otros elementos de LOM. El tipo de datos que se debe proporcionar es un

LangString con una capacidad de al menos 1000 caracteres. Se deben permitir

introducir al menos diez grupos de palabras clave diferentes.

o Cobertura (Coverage). Este elemento define la cobertura espacial y/o

temporal de conceptos tales como: tiempo, cultura, geografía o región física del

objeto educativo. Los valores se expresan de manera textual. El tipo de datos que

se debe proporcionar es un LangString con una capacidad de al menos 1000

caracteres. También se deben permitir introducir al menos diez diferentes.

o Estructura (Structure). Estructura de organización intrínseca del objeto

educativo. El tipo de datos es Vocabulary. Se utiliza para especificarlo un

vocabulario restringido: {Collection, Mixed, Linear, Hierarchical, Networked,

Branched, Parceled, Atomic} (Colección, mixta, lineal, jerárquica, en red,

arboriforme, parcelada, atómica).



o Nivel de agregación (Aggregation Level). El tamaño funcional del objeto

educativo. El tipo de datos es Vocabulary. Pueden utilizarse valores entre '1' y '4'

según el siguiente esquema:

(a) 1. Se refiere al nivel más pequeño de agregación (una imagen o fragmentos de

texto), en terminología LOM se los conoce como átomos.

(b) 2. Se aplica a colecciones de átomos (una página HTML o una lección

con varias imágenes y párrafos).

(c) 3. Indica una colección de elementos de nivel 1 (un sitio web con varias

páginas HTML).

(d) 4. Representa el nivel más grande de granularidad (un curso por

ejemplo).

Ciclo de vida (LifeCycle)

Agrupa las características relacionadas con el ciclo de vida del objeto educativo. En esta

categoría se recogen los siguientes elementos:

o Versión (Version). Se refiere a la edición del objeto educativo. El tipo de datos

que se debe proporcionar es un LangString de al menos 50 caracteres.

o Estatus (Status). Indicará el estado del objeto educativo. El tipo de datos es

Vocabulary. Toma valores de un vocabulario restringido: {Draft, Final, Revised,

Unavailable} (borrador, final, revisado, no disponible).

o Otros colaboradores (Contribute). Personas u organizaciones que han

contribuido y contribuyen al documento. Se incluyen la creación, edición y

publicación. Se debe permitir introducir al menos 30 contribuciones diferentes.

Se forma con los siguientes elementos:

Función (Role). El tipo de contribución. El tipo de datos es Vocabulary. Se

propone la utilización de las figuras siguientes: {Author, Publisher Unknown,

Initiator, Terminator, Validator, Editor, Graphical Designer, Technical

Implementer, Content Provider, Technical Validator, Educational Validator,

Script Writer, Instructional Designer} (autor, editor no conocido, iniciador,

finalizador, validador, editor, diseñador gráfico, implementador técnico,



proveedor de contenidos, validador técnico, validador educativo, guionista,

diseñador instruccional).

Entidad (Entity). Entidad o entidades involucradas. El tipo de datos es una

cadena de caracteres con una capacidad de al menos 1000. Para especificarlo

se utiliza una estructura vCard. Se permitirá introducir un mínimo de

cuarenta entidades diferentes, ordenadas de mayor a menor de relevancia.

Fecha (Date). La fecha en que se realiza la contribución. El tipo de datos que

se debe proporcionar es un Date.

Meta-metainformación (Meta-metadata)

Agrupa las características de la descripción en sí.

o Identificador (Identifier). Identificador único para los metadatos. Puede ser

transparente para la persona que crea los metadatos, siendo definido por el

sistema que los gestiona. Este campo está identificado como reservado

(Reserved) y no lleva asociado ningún tipo de datos.

o Entrada de catálogo (Catalog Entry). Designación dada a la instancia de

metadatos. Este elemento puede utilizarse en lugar del identificador anterior,

pudiendo ser generado automáticamente por la herramienta. Se permitirá

introducir al menos diez designaciones diferentes.

Catálogo (Catalog). Indicación del sistema utilizado para catalogar.

Normalmente es generado por el sistema (por ejemplo: Ariadne). El tipo de

datos es una cadena de caracteres con una capacidad de al menos 1000

caracteres.

Entrada (Entry). Valor con el que se cataloga el documento según el sistema

indicado. También suele ser generado de forma automática por el sistema. El

tipo de datos es LangString con una capacidad de al menos 1000 caracteres.

o Otros colaboradores (Contribute). Personas u organizaciones que

contribuyen a los metadatos. Se permitirá introducir al menos diez

contribuciones en un mismo documento, las cuales mantendrán un orden (el tipo

de orden no está especificado).



Rol (Role). Tipo de contribución. El tipo de datos que se debe proporcionar es

un Vocabulary. Se recomienda utilizar el siguiente vocabulario: {Creator,

Validator}(creador, validador).

Entidad (Entity). Entidad o entidades involucradas. Se podrán introducir al

menos diez entidades poniendo primero las más relevantes. Para especificarlo

se utiliza una estructura vCard. El tipo de datos es una cadena de caracteres de

al menos 1000 caracteres.

Fecha (Date). La fecha en la que se produce la contribución. El tipo de datos que

se debe proporcionar es un Date.

o Esquema de metadatos (MetadataScheme). Nombra la estructura de

metadatos utilizada, incluyendo la versión (por ejemplo: LOM-1.0). El tipo de

datos es una cadena de caracteres con una capacidad de al menos 30 caracteres.

Se permitirá introducir al menos diez valores, si se proporcionan múltiples

valores los metadatos deben ser conformes con todos. Normalmente este valor es

generado de forma automática por el sistema o se permite que el usuario lo

seleccione de una lista.

o Lengua (Language). El

idioma utilizado para

especificar los metadatos.

Se considerará que todos

los elementos que se

especifiquen en forma de

texto utilizan este idioma

por defecto. El tipo de

datos es una cadena de

caracteres con una capacidad de al menos 100 caracteres.

Técnica (Technical)

Aquí se recogen las características técnicas del recurso.



o Formato (Format). Formato del objeto educativo. Se utiliza un vocabulario

restringido: tipo MIME2 (por ejemplo: video/mpeg, text/html) o "non-digital".

Puede utilizarse para identificar el software necesario para acceder al recurso. El


caracteres. Se deben permitir introducir al menos cuarenta formatos diferentes.

o Tamaño (Size). El tamaño del objeto educativo digital en bytes y se refiere al

tamaño real, no al tamaño comprimido. El tipo de datos es una cadena de

caracteres con una capacidad de al menos 30 caracteres.

o Ubicación (Location). La ubicación del objeto educativo o un método que nos

la proporciona (ejemplo: un URL). El tipo de datos es una cadena de caracteres

con una capacidad de al menos 1000 caracteres. Se debe permitir indicar al

menos diez ubicaciones diferentes, empezando por las más recomendadas. Se

recomienda introducir la ubicación primero (antes que un método que resuelva la

ubicación).

o Requisitos (Requirements). Los requisitos que se necesitan para acceder al

objeto educativo. Se permitirá introducir al menos cuarenta diferentes. Pueden

definirse requisitos complejos conectándolos a través del operador lógico “AND”.

Tipo (Type). El tipo de requisito. El tipo de datos que se debe proporcionar es

un Vocabulary. Se recomienda utilizar el siguiente vocabulario: {Operating

System, Browser} (sistema operativo, navegador).

Nombre (Name). Nombre del elemento requerido. El tipo de datos que se debe

proporcionar es un Vocabulary.

Para sistema operativo: PC-DOS, MS-Windows, MacOS, Unix, Multi-OS,

Ninguno (none).

2 Multipurpose Internet Mail Extensions (Extensiones de correo electrónico multiuso). Se

refiere al formato de correo por Internet que permite mensajes textuales en formato ASCII

expandido, mensajes no textuales, cuerpo del mensaje con elementos HTML y gráficos e

información en la cabecera de los mensajes en formato ASCII expandido.

http://www.ietf.org/html.charters/mixer-charter.html.



Para navegador: cualquiera (any), Netscape Communicator, Microsoft

Internet Explorer, Opera, Amaya.

Versión mínima (Minimum Version).Versión mínima que se requiere del

elemento anterior. El tipo de datos es una cadena de caracteres con una


Versión máxima (Maximum Version). Versión máxima que se requiere del

elemento anterior. El tipo de datos es una es una cadena de caracteres con una


o Comentarios sobre la instalación (Installation Remarks). Descripción

textual de cómo instalar el recurso. El tipo de datos que se debe proporcionar es

un LangString con una capacidad de al menos 1000 caracteres.

o Otros requisitos sobre plataformas (Other Platform Requirements).

Información sobre otros requisitos software y hardware (e.g.: tarjeta de sonido).

El tipo de datos que se debe proporcionar es un LangString con una capacidad de


o Duración (Duration). Tiempo que tarda en ejecutarse el recurso a una

velocidad dada, en segundos. Este metadato se utilizará normalmente para

sonidos, películas o animaciones. El tipo de datos que se debe proporcionar es un

Date.

Uso educativo (Educational)

Agrupa las características educativas o pedagógicas del recurso.

o Tipo de interactividad (Interactivity Type). El tipo de interactividad

soportado por el objeto educativo. El tipo de datos es Vocabulary. Se utiliza el

siguiente vocabulario restringido: {Expositive (expositiva: la información va del

recurso al alumno, por ejemplo: videos, documentos hipertexto), Active (activa:

también hay un paso de información del alumno hacia el recurso, por ejemplo:

ejercicios, simuladores), Mixed (mixta), Undefined (no definida).



o Tipo de recurso de aprendizaje (Learning Resource Type). El tipo

específico de objeto educativo. Se permitirá introducir al menos diez diferentes,

empezando por lo que sea más relevante. El tipo de datos que se debe

proporcionar es un Vocabulary. Se recomienda utilizar el siguiente vocabulario:

{Exercise, Simulation, Questionnarie, Diagram, Figure, Graph, Index, Slide,

Table, Narrative Text, Exam, Experiment, Problem Statement, SelfAssesment}

(ejercicio, simulación, cuestionario, diagrama, figura, gráfica, índice, diapositiva,

tabla, texto descriptivo, examen, experimento, presentación de problema,

autoevaluación).

o Nivel de interactividad (Interactivity Level). Nivel de interactividad entre

el usuario y el objeto educativo. El tipo de datos es Vocabulary. Los valores que

puede tomar son:

Muy baja, very low.

Baja, low.

Media, medium.

Alta, high.

Muy alta, very high.

o Densidad semántica (Semantic Density). Medida subjetiva de la utilidad

del objeto educativo en relación con su tamaño o duración. El tipo de datos es

Vocabulary. Los valores que puede tomar son:

Muy baja, very low.

Baja, low.

Media, medium.

Alta, high.

Muy alta, very high.

o Usuario principal (Intended end user role). Usuario al que va dirigido el

objeto educativo. El tipo de datos es Vocabulary. Se permitirá introducir al menos

diez diferentes siguiendo una ordenación (aunque no indican cual), pudiendo

tomar valores del siguiente vocabulario restringido (pero se plantean si quizás

debería ser recomendado): {Teacher, Author, Learner, Manager} (profesor,

autor (crea y publica el recurso), alumno (utiliza el recurso para aprender algo),

gestor (gestiona la entrega del recurso, es por ejemplo una universidad o un

colegio).



o Nivel educativo (Context). El tipo de alumnos a los que va dirigido. El tipo de

datos que se debe proporcionar es un Vocabulary. Se permitirá introducir al

menos diez diferentes y se recomienda la utilización del siguiente vocabulario:

{Primary Education, Secondary Education, Higher Education, University First

Cycle, University Second Cycle, University Postgrade, Technical School First

Cycle, Technical School Second Cycle, Professional Formation, Continuous

Formation, Vocational Training} (educación primaria, educación secundaria,

educación secundaria postobligatoria, universidad primer ciclo, universidad

segundo ciclo, universidad tercer ciclo, escuela técnica primer ciclo, escuela

técnica segundo ciclo, formación profesional, formación continua, formación de

adultos).

o Edad (Typical Age Range). Descripción textual de la edad del usuario al que

va dirigido. El tipo de datos que se debe proporcionar es un LangString de al

menos 1000 caracteres. Se permitirá introducir al menos cinco valores a la vez.

o Dificultad (Difficulty). Indicación de lo difícil que es el objeto educativo para

la audiencia indicada. El tipo de datos es Vocabulary. Los valores que puede

tomar son:

Muy fácil, very easy.

Fácil, easy.

Media, medium.

Difícil, difficult.

Muy difícil, very difficult.

o Tiempo previsto de aprendizaje (Typical Learning Time). Una

estimación del tiempo que requiere el uso del objeto educativo. El tipo de datos

que se debe proporcionar es de tipo Duration.

o Descripción (Description). Comentarios sobre cómo debe utilizarse el objeto

educativo (por ejemplo: indicaciones del profesor que vienen junto con el libro de

texto). El tipo de datos que se debe proporcionar es un LangString con una


o Lengua (Language). El idioma utilizado por los usuarios destinatarios de este

objeto educativo. El tipo de datos que se debe proporcionar es un LangString con

una capacidad de al menos 1000 caracteres. Ya hemos visto varios metadatos que



se refieren al idioma utilizado, si bien cada uno tiene un cometido diferente. Para

entenderlo claramente considérese el siguiente ejemplo, supongamos que

tenemos un curso en inglés para españoles. El metadato General.language

debería ser "inglés", sin embargo el metadato Educational.language debiera ser

castellano. Por su parte el metadato Meta-metadata.language sería el del idioma

utilizado para introducir los metadatos.

Derechos (Rights)

Agrupa las características relativas a las condiciones de uso del recurso. La intención

es utilizar el trabajo realizado por las comunidades de Derechos de la Propiedad

Intelectual y comercio electrónico. Actualmente se cubren únicamente los mínimos

absolutos en estos temas.

o Coste (Cost). Se refiere a que si es gratis o hay que pagar por el recurso. Se

utiliza un vocabulario restringido: {yes, no}(sí, no). El tipo de datos es una

cadena de caracteres con una capacidad de al menos 8 caracteres.

o Copyright y otras restricciones (Copyright and Other Restrictions). Se

refiere al copyright u otras restricciones asociadas a la utilización del recurso. Se

utiliza un vocabulario restringido: {yes, no}(sí, no). El tipo de datos es una

cadena de caracteres con una capacidad de al menos 8 caracteres.

o Descripción (Description). Comentarios sobre las condiciones de uso del

recurso. El tipo de datos que se debe proporcionar es un LOMLangStringType

con una capacidad de al menos 1024 caracteres.

Relación (Relation)

Agrupa las características relativas a las relaciones de este recurso con otros. Se

permitirá introducir al menos 32 relaciones diferentes dentro de un mismo

documento.

o Tipo (Kind). Naturaleza de la relación entre el recurso que se describe y el que

se indica. El tipo de datos que se debe proporcionar es un LOMLangStringType

con una capacidad de al menos 1024 caracteres. Se recomienda utilizar el

siguiente vocabulario (tomado de Dublin Core): {IsPartOf, HasPart, IsVersionOf,



HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn,

IsBasisFor, Requires, IsRequiredBy} (es parte de, tiene parte, es versión de, tiene

una versión, es formato de, referencia, es referenciado por, está basado en, es

base para, requiere, es requerido por).

o Recurso (Resource). El otro recurso al que se refiere la relación.

Identificador (Identificator). Identificador único del recurso. Este campo está

identificado como reservado (Reserved) y no lleva asociado ningún tipo de

datos.

Descripción (Description). Descripción textual del otro recurso. El tipo de datos

que se debe proporcionar es un LOMLangStringType con una capacidad de al

menos 1024 caracteres.

Observaciones (Annotation)

Permite la realización de comentarios sobre la utilización educativa del recurso.

Podrán introducirse al menos 32 comentarios diferentes.

o Persona (Person). Persona que realiza el comentario. Se utiliza una estructura

tipo vCard. El tipo de datos es una cadena de caracteres con una capacidad de al

menos 1024 caracteres.

o Fecha (Date). Fecha en el que fue introducido. El tipo de datos que se debe

proporcionar es un LOMDateType.

o Descripción (Description). Contenido textual del comentario. El tipo de

datos que se debe proporcionar es un LOMLangStringType con una capacidad de


Clasificación (Classification)

Descripción de una característica del recurso para su inclusión en clasificaciones. Se

permitirá introducir al menos diez diferentes, y el usuario final podrá referirse a la

que prefiera.



o Finalidad (Purpose). Características del recurso descrito por esta clasificación

en concreto. El tipo de datos que se debe proporcionar es un

LOMLangStringType de al menos 128 caracteres. Se recomienda utilizar el

siguiente vocabulario: {Discipline, Idea, Prerequisite, Educational Objective,

Accessibility Restrictions, Educational Level, Skill Level, Security Level}

(disciplina, idea, prerrequisito, objetivo educativo, restricciones de accesibilidad,

nivel educativo, nivel de competencia, nivel de seguridad).

o Nivel taxon (TaxonPath). Una ruta taxonómica3 en una clasificación

específica. Podrán introducirse al menos 16 diferentes.

Fuente (Source). Una clasificación específica. Por ejemplo, una taxonomía

oficialmente reconocida (ACM, ARIADNE, etc.), o una definida por el usuario.

Una herramienta puede proporcionar los grupos de nivel más alto para una

clasificación en concreto. El tipo de datos es una cadena de caracteres con una


Taxon (Taxon). Una entrada en una clasificación. Un taxon es un nodo que tiene

una etiqueta o un término definido. Un taxon puede también contener una

designación alfanumérica o un identificador para referencias estandardizadas.

Tanto la etiqueta como la entrada (o las dos) pueden ser utilizadas para

designar un taxon determinado. Una lista ordenada de taxones crea una ruta

taxonómica, es decir una ruta que parte desde una entrada más general a una

entrada más específica en una clasificación. La profundidad de las rutas puede

variar de uno hasta nueve. El tipo de datos que se debe proporcionar es un

LOMLangStringType con una capacidad de al menos 512 caracteres. Se podrán

introducir al menos 16 entradas diferentes siguiendo una orden de lo más

general a lo más específico, ya que un mismo recurso puede englobarse en

diferentes clasificaciones. Un ejemplo: "Física / Acústica / Instrumentos /

Estetoscopio", "Medicina / Diagnósticos / Instrumentos / Estetoscopio".

Id (EntryId). Este elemento define el identificador del taxon, como por ejemplo

un número o una combinación de letras ofrecida por la fuente taxonómica. El


caracteres. Se permitirá introducir hasta 16 valores diferentes ordenados

3 Una taxonomía es una colección estructurada de términos que se utiliza para clasificar

información. Un ejemplo de taxonomía son los sistemas de directorios de los buscadores web.



(aunque no especifica el orden que se debe seguir suponemos que será el

mismo que el de la entrada taxonómica anterior).

o Descripción (Description). Una descripción textual de la característica que se

describe del recurso. El tipo de datos que se debe proporcionar es un

LOMLangStringType con una capacidad de al menos 1024 caracteres.

o Descriptor (Keywords). Una lista de palabras clave que describen la

característica, poniendo las más relevantes primero. El tipo de datos que se debe

proporcionar es un LOMLangStringType con una capacidad de al menos 1024

caracteres. Podrán introducirse al menos ocho grupos de palabras clave

diferentes (no se especifica en qué orden, pero se puede suponer que las más

apropiadas deben ponerse primero).

2.4. Dublin Core Educación (DC)

Dublin Core es una propuesta para metadatos de la Dublin Core Metadata Initiative

(DCMI), una organización dedicada específicamente a la creación, mantenimiento

y gestión de propuestas de metadatos. El nombre de Dublin Core procede de la

ciudad de Estados Unidos (Dublin, estado de Ohio) donde se produjo en 1995 una

reunión de especialistas en la que tuvo lugar el nacimiento de esta iniciativa. “Core”

refleja el hecho de que únicamente se recogieron los elementos más básicos para

garantizar su aplicabilidad a un amplio abanico de tipos de recursos, por supuesto

también en el ámbito de la educación.

Se trata de una propuesta mucho más reducida a LOM (15 elementos frente a los

más de 60 de LOM). Cada uno de los elementos, con un nombre que pretende ser auto-

descriptivo, es opcional y puede repetirse. Los elementos pueden aparecer en cualquier

orden.



Los quince elementos de Dublin Core pretenden describir un recurso desde tres puntos

de vista diferentes:

1 Contenido del recurso

2 Características desde el punto de vista de propiedad intelectual

3 Propiedades relacionadas con la instanciación del recurso

1 Dentro del grupo relacionado con el contenido se incluyen los siguientes

elementos:

1 Título (Title). El nombre del recurso. Ejemplo: “Simulador B747”.

2 Tópico (Subject). La temática del recurso. Se intentará utilizar claves o frases que

describen el contenido del recurso. Si es posible usando vocabularios controlados.

Ejemplo: “Simuladores aviación civil”.

3 Descripción (Description). Una descripción textual del recurso. Ejemplo:

“Simulador de piloto y co-piloto para la aeronave Boing 747, incluyendo elementos

que permiten la simulación de todos los mecanismos y procedimientos incluidos en

el manual oficial de vuelo proporcionado por el fabricante”.

4 Fuente (Source). Recurso relacionado con el que se describe y del cual procede.

Ejemplo: “http://www.boeing.com/software”.

5 Idioma (Language). Idioma principal en el que está el recurso. Ejemplo: “en-

US”.

6 Relación (Relation). Identificador de un recurso con el cual este está relacionado.

Ejemplo: http://www.boeing.com/software/simulators/boeing777.

7 Cobertura (Coverage). Define la cobertura espacial o temporal del recurso.

Ejemplo: “Estados Unidos y Europa”

2 Dentro del grupo relacionado con la propiedad intelectual:

8 Creador (Creator). Persona u organización responsable de la creación del

recurso. Ejemplo “Boeing supporting software Ltd”.

9 Editor (Publisher). La entidad responsable de que el recurso esté disponible en

su formato actual. Ejemplo: “Boeing supporting software Ltd”.



10 Otros Colaboradores (Contributor). Persona u organización que ha realizado

una contribución destacada para el recurso que se describe. Ejemplo: “Dr. James

Smith”.

11 Derechos (Rights). Explicación sobre las características del recurso en cuanto a

sus derechos de uso. Ejemplo: “Uso bajo licencia”.

3 Dentro del grupo instanciación:

12 Fecha (Date). Fecha en la que el recurso fue publicado en su forma actual.

Ejemplo: “2011-11-02”.

13 Tipo del Recurso (Type). Categoría del recurso. Ejemplo: “Simulador software”.

14 Formato (Format). Es el formato de datos del recurso, utilizado para identificar

el soporte (e.g. software y hardware) necesario para su uso. Ejemplo: “Java applet”.

15 Identificador del recurso (Identifier). Secuencia de caracteres utilizados para

identificar de forma unívoca al recurso. Ejemplo:

http://www.boeing.com/software/simulators/boeing747.

2.5. Los perfiles de aplicación. Variaciones sobre DC y LOM

Un perfil de aplicación es un refinamiento de una especificación (o un conjunto de

ellas) para facilitar su utilización por parte de una comunidad de práctica determinada.

Algunas de las razones para desarrollar un perfil de aplicación pueden ser:

Satisfacer los requisitos técnicos o de otro tipo y las preferencias específicas de un

proyecto, comunidad, dominio o región.

Reducir la ambigüedad y generalidad en una especificación o estándar.

Promover la interoperabilidad semántica, por ejemplo, mediante el uso de

vocabularios comunes.

Facilitar la comprobación de compatibilidad e interoperabilidad.

Existen diversas fuentes que buscan definir de forma más precisa lo que deben ser los

perfiles de aplicación y definir reglas a seguir cuando se genere un perfil de

aplicación. Se pueden extraer las siguientes conclusiones de las recomendaciones

comunes realizadas por todas ellas:



Selección de un conjunto de sub-elementos y campos de la especificación/esquema

fuente. Probablemente identificando el sub-conjunto de elementos mínimo que se

considerará como obligatorio.

La incorporación de elementos y/o campos propios del perfil de aplicación

(normalmente llamados “extensiones”) a la especificación/esquema fuente.

Imposición de restricciones adicionales sobre un elemento para reflejar las

necesidades de la comunidad de uso del perfil de aplicación. Por ejemplo, sustituir el

tipo de valores de un elemento pasando de texto libre a un vocabulario controlado.

Producción de una descripción exhaustiva de la semántica y uso que se debe realizar

de cada uno de los elementos dentro de la comunidad de uso del perfil de aplicación.

El proceso de desarrollo de un perfil de aplicación se caracteriza por las siguientes

actividades:

1 Localización: la especialización de uno o más modelos de datos conceptuales

(especificaciones fuente) a las necesidades específicas de una comunidad, generando

una especificación derivada.

2 Representación: identificación en una tecnología concreta (por ejemplo XML) del

modelo conceptual derivado.

3 Transacción: definición de cómo la interfaz abstracta y modelo de servicio, i.e. la

API y las transacciones implicadas, serán utilizadas con una tecnología concreta.

Algunas de las instituciones más relevantes en el proceso de estandarización, como el

CEN, IMS o la Dublin Core Metadata Initiative, han publicado

documentos en los que recogen sus recomendaciones para la

generación de perfiles de aplicación.

Tanto en el caso de Dublin Core como de LOM se han desarrollado durante los últimos

años perfiles de aplicación para diferentes comunidades de uso. En el caso de LOM, al

margen del desarrollo de perfiles para dominios temáticos concretos, han tenido

especial relevancia los perfiles desarrollados en diferentes países, entre ellos España:

LOM-ES, desarrollado por AENOR en España.

UK LOM Core, si bien no está activo en la actualidad, ha sido una de las primeras

iniciativas, llevadas a cabo en el Reino Unido, centrándose en la educación superior.



Cancore, se trata de una guía muy extensa sobre la interpretación e

implementación de cada uno de los elementos de LOM. Ha sido desarrollada por

expertos canadienses.

ANZ-LOM es el perfil de aplicación desarrollado para Australia y Nueva Zelanda.

Ofrece interpretaciones de la estructura de LOM y cómo aplicar los vocabularios

controlados, especialmente a través de la categoría “clasificación”.

Vetadata, desarrollado también es Australia, se centra en la descripción de recursos

para aprendizaje vocacional.

NORLOM, es el perfil noruego, desarrollado por el organismo oficial de

estandarización de este país.

ISRACORE, perfil desarrollado por una universidad de Israel y la asociación de

Internet del país hebreo.

SWE-LOM, perfil de aplicación para Suecia desarrollado bajo el amparo del

organismo de normalización sueco.

LOM-FR, perfil de aplicación desarrollado por AFNOR, la asociación para la

normalización en Francia.

Los anteriores son solo algunos ejemplos de los múltiples perfiles de aplicación

desarrollados en diferentes países. Se incluyen referencias a algunos de ellos en la

sección +Información para que el alumno interesado pueda profundizar en su

estudio.

En el caso de Dublin Core tenemos un grupo de trabajo dedicado a desarrollar este

esquema para el ámbito de la Educación. Se trata de la especificación Dublin Core

Education (DC-Ed) que todavía se encuentra en fase de desarrollo. Existen también

otros perfiles de aplicación de Dublin Core para diferentes ámbitos además del de la

educación, por ejemplo para bibliotecas o para administración/gobierno.


TEMA 2 – Lo + recomendado

Lo + recomendado

No dejes de leer…

Metadatos para Objetos Educativos

Luis Anido y Miguel Rodríguez Artacho.

CEN WS-LT.

Traducción oficial al español del estándar LOM, avalada por el Comité Europeo de

Normalización

Artículo disponible en el aula virtual o en la siguiente dirección web:

http://www.cen.eu/cen/Sectors/Sectors/ISSS/Activity/Pages/Lom_Trans_Spanish.aspx

Dublin Core Metadata Element Set. Version 1.1

En este documento se presenta la descripción oficial, proporcionada por el DCMI de los

quince elementos que conforman la especificación Dublin Core.


http://dublincore.org/documents/dces/

IEEE LTSC P1484. “Learning Object Metadata” IEEE SA. Julio de 2002

En este documento se recoge la versión final del estándar LOM. Este documento es

muy relevante tanto para este tema como para la realización del trabajo final del curso.


http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf


TEMA 2 – Lo + recomendado

ISO/IEC 19788 MLR: un Nuevo estándar de metadatos para recursos

educativos

Daniel Pons, José Ramón Hilera, Carmen Pages.

IEEE RITA. Edición especial sobre “Adoptando Estándares y Especificaciones para

Contenidos Educativos”. Agosto de 2011.

En este artículo se realiza una primera aproximación al nuevo estándar para metadatos

educativos de la ISO y se realiza un análisis comparativo con LOM y DC.


http://rita.det.uvigo.es

LOM-ES. Perfil de aplicación de LOM para España

En este sitio web se realiza una introducción al perfil de aplicación LOM para España.

Este perfil ha sido aprobado como norma UNE por parte de AENOR CTN71 SC36.


http://www.lom-es.es

Guidelines and support for building application profiles in elearning

Neil Smith, Marc van Coillie, Erik Duval.

CEN CWA 15555. 2006.

Este CEN Workshop Agreement realiza una aproximación a los perfiles de aplicación

para especificaciones en el campo del elearning y establece una serie de

recomendaciones para su elaboración.


ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15555-00-2006-Jun.pdf


TEMA 2 – + Información

+ Información

A fondo

Educational Metadata and Brokerage for Learning Resources

Luis Anido, Manuel Fernández, Manuel Caeiro, Juan Santos, Judith Rodríguez, Martín

Llamas. Computers and Education. Vol 38. Issue 4. Mayo 2002. Páginas: 351-374.

En este artículo se realiza un análisis comparativo de las principales propuestas para

metadatos educativos, todavía vigentes hoy en día. Asimismo se presenta uno de sus

principales campos de aplicación: los sistemas de intermediación para la localización

de recursos educativos.


http://www.sciencedirect.com/science/article/pii/S0360131502000180

Dublin Core Metadata Initiative “DC Education Applicacion Profile”

Página del grupo de trabajo que se encarga del desarrollo del perfil de aplicación de

Dublin Core para Educación. Se trata de un excelente ejemplo de un perfil de aplicación

de una especificación para metadatos, además para el campo educativo.


http://dublincore.org/educationwiki/DC_2dEducation_20Application_20Profile

Bibliografía

F. Farance, “IEEE LOM standard not yet ready for prime time," IEEE Learning

Technology Newsletter, 5(1), 21-23, 2003.

ISO, “ISO/IEC 19788. Information technology for learning, education and training.

Metadata for Learning Resource,” International Standards Organization, (Working

Draft), 2011.



Webgrafía

Perfil de aplicación de Dublin Core

Especificación del perfil de Dublin Core para bibliotecas.

Para bibliotecas: http://dublincore.org/documents/library-application-profile

Para administración/gobierno: http://dublincore.org/documents/2001/09/17/gov-

application-profile

Perfil de aplicación de LOM francés

Perfil de aplicación de LOM para Francia.

http://www.lom-fr.fr

Perfil de aplicación SWE-LOM

Perfil de aplicación de LOM para Suecia.

http://www.swe-lom.se/

Perfil de aplicación UK LOM Core

Perfil de aplicación de LOM para el Reino Unido

http://metadata.cetis.ac.uk/profiles/uklomcore

Perfil de aplicación Vetadata

Perfil de aplicación de LOM para vocational training.

http://e-standards.flexiblelearning.net.au/vetadata/



Phil Barker “What is IEEE Learning Object Metadata / IMS Learning

Resource Metadata?”

Introducción a la especificación LOM.

http://metadata.cetis.ac.uk/guides/WhatIsLOM.pdf

Especificaciones de metadatos de IMS

Especificación de metadatos de IMS.

http://www.imsglobal.org/metadata

Especificaciones de metadatos de ADL. Incluidas dentro de SCORM 2004

Especificación de metadatos de SCORM.

http://www.adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM%202004%204

th%20Ed%20V1.1/Documentation%20Suite/SCORM_2004_4ED_v1_1_Doc_Suite.zip

Especificación de metadatos de la iniciativa norteamericana GEM

Metadatos de la iniciativa GEM.

http://www.thegateway.org/

Especificación de metadatos de la iniciativa australiana EdNA

Metadatos de EdNA.

http://www.edna.edu.au/metadata/

Especificación de metadatos de la European SchoolNet

Especificación de metadatos para el repositorio de la European SchoolNet.

http://lreforschools.eun.org/c/document_library/get_file?p_l_id=10970&folderId=12

073&name=DLFE-1.pdf



International Standards Organization (ISO). (1988) Code for the

representation of names of languages

Estándar ISO para la codificación de los identificadores de idiomas

http://www.iso.ch/cate/d4766.html

International Standards Organization (ISO). (1988) Data element and

interchange format. Information interchange. Representation of dates

and times

Estándar ISO para la codificación de la identificación de las fechas.

http://www.iso.ch/markete/8601.pdf

International Standards Organization.(2000) Information Technology.

Universal multiple-octet Coded Carácter Set (UCS). Part 1: Architecture

and Basic Multilingual Plane

Estándar ISO para la codificación de caracteres.


International Standards Organization (ISO). (1996) Information

technology. Programming languages, their environments and system

software interfaces. Language-independent datatypes

Estándar ISO para la especificación de tipos de datos de forma independiente al

idioma.


Kunze, J. (1999) Encoding Dublin Core Metadata in HTML (RFC 2731)

Representación de Dublin Core en HTML.

http://www.ietf.org/rfc/rfc2731.txt



Juan Rouyect y Víctor Martín. “A comparative study of the metadata in

SCORM and Dublin Core”

Estudio sobre los metadatos SCORM y Dublin Core.

http://spdece.uah.es/papers/Rouyet_Final.pdf

Sarah Currier. “Metadata for Learning Resources: An unpdate on

standards activity for 2008”

Presentación de la situación en la estandarización de metadatos para recursos

educativos.

http://www.ariadne.ac.uk/issue55/currier/

David A Willey II. “Connecting learning objects to instructional design

theory: A definition, a metaphor and a taxonomy”

Trabajo sobre la utilización de objetos educativos como parte de diseños

instruccionales.

http://www.mendeley.com/research/connecting-learning-objects-to-instructional-

design-theory-a-definition-a-metaphor-and-a-taxonomy/

Guidelines for Dublin Core Application Profiles

Guías para la creación de perfiles de aplicación Dublin Core.

http://dublincore.org/documents/profile-guidelines/

IMS Application profile guidelines

Guías para la creación de perfiles de aplicación de IMS.

http://www.imsglobal.org/ap/index.html


TEMA 2 – Actividades

Actividades

Descripción usando LOM

En esta actividad realizaremos una descripción de un objeto educativo utilizando

únicamente la categoría “General” de LOM. La descripción podrá entregarse en

forma de tabla, con un formato similar al incluido a continuación:

Nr Name Valor

1 General

1.1 Identifier

1.1.1 Catalog

1.1.2 Entry

1.2 Title

1.3 Language

1.4 Description

1.5 Keyword

1.6 Coverage

1.7 Structure

1.8 Aggregation Level

En caso de que sea necesario el alumno debe realizar todas aquellas suposiciones que

estime convenientes debiendo ser estas explicadas al comienzo de la solución a la

actividad.

El objeto educativo a describir se encuentra en:

http://upload.wikimedia.org/wikipedia/commons/4/4e/Vel%C3%A1zquez_-

_de_Breda_o_Las_Lanzas_%28Museo_del_Prado%2C_1634-35%29.jpg


TEMA 2 – Test

Test

1. ¿Qué objetivos persigue la utilización de un esquema de metadatos?

A. Facilitar la clasificación de un objeto educativo.

B. Facilitar la búsqueda de un objeto educativo.

C. Facilitar la descripción de un objeto educativo.

D. Todas las anteriores.

2. ¿Cuáles de las siguientes afirmaciones son correctas?

A. Todos los elementos de LOM son opcionales.

B. Un perfil de aplicación de LOM puede sustituir la semántica original de un

elemento definido en el esquema base de LOM si es necesario.

C. Una instancia de LOM debe contener al menos los elementos marcados como

obligatorios en la especificación.

D. Una implementación de LOM es estrictamente conforme a la especificación si

contiene al menos un elemento de cada una de las categorías.

3. ¿Qué estructura se utiliza en LOM para introducir textos equivalentes en diferentes

idiomas?

A. LangString.

B. Language.

C. Vocabulary.

D. General.

4. ¿Cuántas categorías tiene LOM?

A. 5.

B. 7.

C. 9.

D. 11.

5. El elemento “Language”, incluido dentro de la categoría “Educational” de LOM

indica:

A. El idioma en el que se realiza la descripción del recurso educativo.

B. El idioma de los usuarios a los que va dirigido el recurso.

C. El idioma por defecto de las cadenas de soporte multilingüe.

D. El idioma utilizado en el recurso.


TEMA 2 – Test

6. ¿Cuál es el tipo de datos del elemento “Difficulty” de LOM?

A. CharacterString.

B. Numeric.

C. Vocabulary.

D. Ninguna de las anteriores.

7. En LOM el concepto smallest permitted maximum se refiere a:

A. El menor valor que se permite para una cota superior en un elemento de datos.

B. El máximo valor que se permite para un elemento de datos.

C. El menor valor de entre varios máximos en los elementos de una categoría.

D. Ninguna de las anteriores.

8. La especificación Dublin Core ¿incluye un elemento denominado “Rights”?

A. Verdadero.

B. Falso.

9. ¿Cuántos elementos define la especificación Dublin Core?

A. 12.

B. 15.

C. 20.

D. 23

10. ¿Cuáles de los siguientes son perfiles de aplicación de LOM?

A. LOM-FR.

B. LOM-ES.

C. NORLOM.

D. Todas las anteriores.

tema2encontrar un recurso educativo. los metadatos

Documents

tic tema

estndar lom

definicin de metadatos

norma lom

ejemplo de lom

especificacin lom

dc tema especificaciones

ideas clave ideas clave