
jueves, 18 de febrero de 2010
jueves, 11 de febrero de 2010
Manual De Usuario
Es donde se expone los procesos que el usuario puede realizar con el sistema implantado. Es decir, es donde se detallan todas y cada una de las características que tienen los programas y la forma de acceder e introducir información. Permite a los usuarios conocer el detalle de qué actividades ellos deberán desarrollar para la consecución de los objetivos del sistema. Reúne la información, normas y documentación necesaria para que el usuario conozca y utilice adecuadamente la aplicación desarrollada.
Objetivos
• Que el usuario conozca cómo preparar los datos de entrada.
• Que el usuario aprenda a obtener los resultados y los datos de salida.
• Servir como manual de aprendizaje.
• Servir como manual de referencia.
• Definir las funciones que debe realizar el usuario.
• Informar al usuario de la respuesta a cada mensaje de error.
Pasos a seguir para definir como desarrollar el manual de usuario.•
Identificar los usuarios del sistema: personal que se relacionará con el sistema.
• Definir los diferentes tipo de usuarios: se presentan los diferentes tipos de usuarios que usarían el sistema. Ejemplo: usuarios directos, indirectos.
• Definir los módulos en que cada usuario participará: Se describen los módulos o procesos que se ejecutarán por cada usuario en forma narrativa breve y clara.
Importancia Del Manual De Usuario
El Manual de Usuario facilita el conocimiento de:
• Los documentos a los que se puede dar entrada por computadora.
• Los formatos de los documentos.
• Las operaciones que utiliza de entrada y salida de los datos.
• El orden del tratamiento de la computadora con los datos introducidos.
• El momento en que se debe solicitar una operación deseada.
• Los resultados de las operaciones realizadas a partir de los datos introducidos.
Al elaborar el Manual de Usuario, hay que tener en cuenta a quién va dirigido es decir, el manual puede ser manejado desde el director de la empresa hasta el introductor de datos. Por consiguiente, debe redactarse de forma clara y sencilla para que lo entienda cualquier tipo de usuario.
Contenido
Diagrama general del sistema
Muestra en forma condensada el flujo general de la información y de las actividades que se realizan en el sistema. Proporciona una visión general del sistema. Representar los diagramas utilizando para ello diagramas de bloques.
Diagrama particular detallado.
Presentar gráficamente todos los pasos que se efectúen dentro del departamento usuario a quien está dirigido este manual. Deben especificarse los archivos de entrada, salida, los resultados, revisiones y procesos manuales.
Explicación Genérica De Las Fases Del Sistema
En este punto se explica en forma específica y detallada todas las operaciones que aparecen representadas en forma gráfica en el diagrama particular. Se analizan cada una de las fases señalando:
El proceso principal que se desarrolla.
La entrada de la información.
La obtención de un resultado parcial.
El envío de información a otra dependencia.
Instalación Del Sistema
La instalación del sistema proporciona detalles completos sobre la forma de instalar el sistema en un ambiente particular.
Iniciación Al Uso Del Sistema
En este punto se explica cómo iniciarse en el sistema y cómo se pueden utilizar sus cualidades comunes. Esta documentación debe decir al usuario cómo salir de un problema cuando las cosas funcionan mal.
Manual De Referencia
Es el documento definitivo de cara al usuario y debe ser completo. Describe con detalle las cualidades del sistema y su uso, los informes de error generados y las situaciones en que surgen esos errores.
Dependiendo del sistema, los documentos al usuario se pueden proporcionar por separado o reunidos en varios volúmenes. Los sistemas de ayuda en línea evitan que el usuario pierda tiempo en consultas manuales.
Caducidad De Documento Fuente Y Destino Final
Como el usuario trabajará con documentos fuentes, éstos podrán tener un período de retención y un destino especificado.
Objetivos
• Que el usuario conozca cómo preparar los datos de entrada.
• Que el usuario aprenda a obtener los resultados y los datos de salida.
• Servir como manual de aprendizaje.
• Servir como manual de referencia.
• Definir las funciones que debe realizar el usuario.
• Informar al usuario de la respuesta a cada mensaje de error.
Pasos a seguir para definir como desarrollar el manual de usuario.•
Identificar los usuarios del sistema: personal que se relacionará con el sistema.
• Definir los diferentes tipo de usuarios: se presentan los diferentes tipos de usuarios que usarían el sistema. Ejemplo: usuarios directos, indirectos.
• Definir los módulos en que cada usuario participará: Se describen los módulos o procesos que se ejecutarán por cada usuario en forma narrativa breve y clara.
Importancia Del Manual De Usuario
El Manual de Usuario facilita el conocimiento de:
• Los documentos a los que se puede dar entrada por computadora.
• Los formatos de los documentos.
• Las operaciones que utiliza de entrada y salida de los datos.
• El orden del tratamiento de la computadora con los datos introducidos.
• El momento en que se debe solicitar una operación deseada.
• Los resultados de las operaciones realizadas a partir de los datos introducidos.
Al elaborar el Manual de Usuario, hay que tener en cuenta a quién va dirigido es decir, el manual puede ser manejado desde el director de la empresa hasta el introductor de datos. Por consiguiente, debe redactarse de forma clara y sencilla para que lo entienda cualquier tipo de usuario.
Contenido
Diagrama general del sistema
Muestra en forma condensada el flujo general de la información y de las actividades que se realizan en el sistema. Proporciona una visión general del sistema. Representar los diagramas utilizando para ello diagramas de bloques.
Diagrama particular detallado.
Presentar gráficamente todos los pasos que se efectúen dentro del departamento usuario a quien está dirigido este manual. Deben especificarse los archivos de entrada, salida, los resultados, revisiones y procesos manuales.
Explicación Genérica De Las Fases Del Sistema
En este punto se explica en forma específica y detallada todas las operaciones que aparecen representadas en forma gráfica en el diagrama particular. Se analizan cada una de las fases señalando:
El proceso principal que se desarrolla.
La entrada de la información.
La obtención de un resultado parcial.
El envío de información a otra dependencia.
Instalación Del Sistema
La instalación del sistema proporciona detalles completos sobre la forma de instalar el sistema en un ambiente particular.
Iniciación Al Uso Del Sistema
En este punto se explica cómo iniciarse en el sistema y cómo se pueden utilizar sus cualidades comunes. Esta documentación debe decir al usuario cómo salir de un problema cuando las cosas funcionan mal.
Manual De Referencia
Es el documento definitivo de cara al usuario y debe ser completo. Describe con detalle las cualidades del sistema y su uso, los informes de error generados y las situaciones en que surgen esos errores.
Dependiendo del sistema, los documentos al usuario se pueden proporcionar por separado o reunidos en varios volúmenes. Los sistemas de ayuda en línea evitan que el usuario pierda tiempo en consultas manuales.
Caducidad De Documento Fuente Y Destino Final
Como el usuario trabajará con documentos fuentes, éstos podrán tener un período de retención y un destino especificado.
miércoles, 27 de enero de 2010
Organización general para la documentación de Sistemas
La descripción de la solución adoptada para la realización de un sistema propuesto puede hacerse de formas muy variadas.
La finalidad de este documento es proponer una forma simple de abordar ese problema para que sea usada en la presentación de prácticas de laboratorio en las que se exija la implementación de una solución completa. Estas normas deberán entenderse como un mínimo orientativo en la organización de dicha documentación.
La documentación de un sistema deberá dividirse en las siguientes partes :
• Documentación de construcción.
• Índice de contenido.
• Especificación.
• Arquitectura.
• Módulos de nivel 1.
• Módulos de nivel 2.
• Módulos de nivel n.
• Documentación de uso.
• Manual del usuario.
• Configuración del sistema.
• Documentación complementaria.
• Restricciones del ambiente operativo de ejecución.
• Ejemplos de test, salidas típicas, etc.
• Errores.
• Bibliografía utilizada.
• Documentación relativa al código.
• Documentación sobre la organización del código.
• Código fuente.
Documentación de construcción
Índice de contenido:
Es una tabla que contiene las páginas de comienzo de cada una de las partes que siguen.
Especificación:
Una descripción de lo que debe hacer el sistema, idealmente sin entrar en cómo va a hacerlo.
Arquitectura:
Debe describirse qué partición del problema se ha realizado indicando qué módulos se han usado, qué misión realiza cada uno y qué relaciones hay entre ellos.
Módulos de un nivel cualquiera:
Habrá una serie de módulos de primer nivel, cada uno de los cuales se subdividirá en otros módulos de segundo nivel y así sucesivamente hasta completar el sistema.
En cada módulo deberá describirse su utilidad global, los servicios públicos que presta y qué módulos los utilizan.
Igualmente si ciertos servicios del módulo se prestan mediante la petición de servicios a módulos de nivel inferior, deberá decirse qué módulos son utilizados por el que estamos documentando.
Normalmente un módulo subordinado estará construido en torno a la implementación de los servicios de uno o varios tipos abstractos de datos de interés para la aplicación.
Es frecuente realizar el módulo de nivel más alto como un módulo de control que solicita los servicios de más alto nivel a otros módulos subordinados, en los que delega para realizar el trabajo de otros niveles inferiores. Incluso esa estrategia es aplicable a los módulos de niveles más bajos, pero deberá evitarse acoplamientos entre módulos en los que algunos módulos de nivel bajo pidan servicios a módulos de nivel superior.
Para describir las funciones que componen un módulo se separarán las descripciones de las funciones pertenecientes al interfaz público de las demás.
Cada función se documentará indicando su finalidad. Se especificará su prototipo y se comentará la semántica, el formato y el uso de cada uno de los argumentos y del resultado, indicando asimismo las restricciones de uso si la implementación depende del sistema operativo.
Documentación de uso Manual del usuario
Se documentarán en esta sección las formas de uso del sistema a través del interfaz de usuario o de comunicaciones que se haya previsto, poniendo ejemplos de uso legal y su salida típica.
Configuración del sistema
Se comentará aquí el conjunto de valores de las constantes de configuración que el sistema asumirá por defecto, indicando sus significados y señalando las formas de hacer los cambios que puedan necesitarse.
Documentación complementaria
Restricciones del ambiente operativo de ejecución
En esta sección deben comentarse las particularidades que nuestro sistema necesite para ser ejecutado como servicios del sistema operativo o de comunicaciones que se usan de modo explícito y que podrían afectar a la portabilidad del código, etc.
Ejemplos de test, salidas típicas, etc.
Incluiremos aquí una serie de ejemplos de salidas proporcionadas por el sistema en condiciones normales de uso.
Errores
Se documentarán en esta sección los errores detectados por el sistema, sus correspondientes
mensajes de error, su significado y si son recuperables o no, indicando el procedimiento de recuperación si lo hay.
Bibliografía utilizada
Se documentará aquí la bibliografía usada para el diseño e implementación del sistema.
Documentación relativa al código
Documentación sobre la organización del código. Se indicará aquí la estructuración de los archivos que componen el código en los directorios correspondientes y toda la información necesaria para compilar y enlazar los distintos módulos que se hayan usado, tanto los implementados directamente por el desarrollador como los archivos objeto y las bibliotecas no estándares que deban utilizarse.
Código fuente
Por último se acompaña un listado organizado por módulos del sistema objeto del trabajo, junto a los archivos auxiliares necesarios para su instalación, configuración, compilación, enlace y ejecución.
La finalidad de este documento es proponer una forma simple de abordar ese problema para que sea usada en la presentación de prácticas de laboratorio en las que se exija la implementación de una solución completa. Estas normas deberán entenderse como un mínimo orientativo en la organización de dicha documentación.
La documentación de un sistema deberá dividirse en las siguientes partes :
• Documentación de construcción.
• Índice de contenido.
• Especificación.
• Arquitectura.
• Módulos de nivel 1.
• Módulos de nivel 2.
• Módulos de nivel n.
• Documentación de uso.
• Manual del usuario.
• Configuración del sistema.
• Documentación complementaria.
• Restricciones del ambiente operativo de ejecución.
• Ejemplos de test, salidas típicas, etc.
• Errores.
• Bibliografía utilizada.
• Documentación relativa al código.
• Documentación sobre la organización del código.
• Código fuente.
Documentación de construcción
Índice de contenido:
Es una tabla que contiene las páginas de comienzo de cada una de las partes que siguen.
Especificación:
Una descripción de lo que debe hacer el sistema, idealmente sin entrar en cómo va a hacerlo.
Arquitectura:
Debe describirse qué partición del problema se ha realizado indicando qué módulos se han usado, qué misión realiza cada uno y qué relaciones hay entre ellos.
Módulos de un nivel cualquiera:
Habrá una serie de módulos de primer nivel, cada uno de los cuales se subdividirá en otros módulos de segundo nivel y así sucesivamente hasta completar el sistema.
En cada módulo deberá describirse su utilidad global, los servicios públicos que presta y qué módulos los utilizan.
Igualmente si ciertos servicios del módulo se prestan mediante la petición de servicios a módulos de nivel inferior, deberá decirse qué módulos son utilizados por el que estamos documentando.
Normalmente un módulo subordinado estará construido en torno a la implementación de los servicios de uno o varios tipos abstractos de datos de interés para la aplicación.
Es frecuente realizar el módulo de nivel más alto como un módulo de control que solicita los servicios de más alto nivel a otros módulos subordinados, en los que delega para realizar el trabajo de otros niveles inferiores. Incluso esa estrategia es aplicable a los módulos de niveles más bajos, pero deberá evitarse acoplamientos entre módulos en los que algunos módulos de nivel bajo pidan servicios a módulos de nivel superior.
Para describir las funciones que componen un módulo se separarán las descripciones de las funciones pertenecientes al interfaz público de las demás.
Cada función se documentará indicando su finalidad. Se especificará su prototipo y se comentará la semántica, el formato y el uso de cada uno de los argumentos y del resultado, indicando asimismo las restricciones de uso si la implementación depende del sistema operativo.
Documentación de uso Manual del usuario
Se documentarán en esta sección las formas de uso del sistema a través del interfaz de usuario o de comunicaciones que se haya previsto, poniendo ejemplos de uso legal y su salida típica.
Configuración del sistema
Se comentará aquí el conjunto de valores de las constantes de configuración que el sistema asumirá por defecto, indicando sus significados y señalando las formas de hacer los cambios que puedan necesitarse.
Documentación complementaria
Restricciones del ambiente operativo de ejecución
En esta sección deben comentarse las particularidades que nuestro sistema necesite para ser ejecutado como servicios del sistema operativo o de comunicaciones que se usan de modo explícito y que podrían afectar a la portabilidad del código, etc.
Ejemplos de test, salidas típicas, etc.
Incluiremos aquí una serie de ejemplos de salidas proporcionadas por el sistema en condiciones normales de uso.
Errores
Se documentarán en esta sección los errores detectados por el sistema, sus correspondientes
mensajes de error, su significado y si son recuperables o no, indicando el procedimiento de recuperación si lo hay.
Bibliografía utilizada
Se documentará aquí la bibliografía usada para el diseño e implementación del sistema.
Documentación relativa al código
Documentación sobre la organización del código. Se indicará aquí la estructuración de los archivos que componen el código en los directorios correspondientes y toda la información necesaria para compilar y enlazar los distintos módulos que se hayan usado, tanto los implementados directamente por el desarrollador como los archivos objeto y las bibliotecas no estándares que deban utilizarse.
Código fuente
Por último se acompaña un listado organizado por módulos del sistema objeto del trabajo, junto a los archivos auxiliares necesarios para su instalación, configuración, compilación, enlace y ejecución.
¿ Qué es la Normalización?
Asegúrese de que los estándares sean completos, actualizados, documentados y legibles.
Auditar permanentemente para que se cumplan los estándares.
Evaluar si los estándares establecidos son los requeridos y hacer los cambios necesarios para que dichos estándares sean los apropiados.
Teoria General De Los Manuales De Documentación
Durante el desarrollo de un sistema, desde su concepción hasta su puesta en marcha se ha generado gran cantidad de documentos, que en muchas ocasiones se han visto modificados por documentos posteriores debido a cambios en el sistema.
Para evitar confusiones en las revisiones de la documentación se desarrollan diferentes tipos de documentos dirigidos a las personas que trabajarán con el sistema y para facilitar el mantenimiento del mismo. La documentación de un sistema debe ser marcada adecuadamente, bien organizada actualizada y completa; todos los términos utilizados deben explicarse. La documentación se hará disponible a todos los usuarios dc acuerdo a sus necesidades.
El estilo de redacción de los manuales de documentación debe ser:
Concreto.
Ser preciso y definir los términos utilizados.
Utilizar párrafos cortos.
Utilizar títulos y subtítulos.
Utilizar formas activas en lugar de pasivas.
No emplear frases largas que presenten hechos distintos.
No hacer referencia a una información solamente con el número de referencia
Auditar permanentemente para que se cumplan los estándares.
Evaluar si los estándares establecidos son los requeridos y hacer los cambios necesarios para que dichos estándares sean los apropiados.
Teoria General De Los Manuales De Documentación
Durante el desarrollo de un sistema, desde su concepción hasta su puesta en marcha se ha generado gran cantidad de documentos, que en muchas ocasiones se han visto modificados por documentos posteriores debido a cambios en el sistema.
Para evitar confusiones en las revisiones de la documentación se desarrollan diferentes tipos de documentos dirigidos a las personas que trabajarán con el sistema y para facilitar el mantenimiento del mismo. La documentación de un sistema debe ser marcada adecuadamente, bien organizada actualizada y completa; todos los términos utilizados deben explicarse. La documentación se hará disponible a todos los usuarios dc acuerdo a sus necesidades.
El estilo de redacción de los manuales de documentación debe ser:
Concreto.
Ser preciso y definir los términos utilizados.
Utilizar párrafos cortos.
Utilizar títulos y subtítulos.
Utilizar formas activas en lugar de pasivas.
No emplear frases largas que presenten hechos distintos.
No hacer referencia a una información solamente con el número de referencia
La documentación de sistemas
La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen.
La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar.
Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuarios en forma general la naturaleza y capacidades del sistema y cómo usarlo.
Muchas organizaciones tienen lo que se conoce como un "programa de documentación", el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas.
Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes elementos:
Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento.
El diseño del sistema de información administrativo.
Procedimientos para instalar el sistema de información administrativo.
Procedimientos para operar el sistema de información administrativo.
Procedimientos para mantener el sistema de información administrativo.
Importancia De La Documentación De Sistemas
La importancia de la documentación bien podría ser comparada con la importancia de la existencia de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza de Seguros está o no vigente.
La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.
Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará involucrado y no podrá moverse a otra asignación.
La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar.
Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuarios en forma general la naturaleza y capacidades del sistema y cómo usarlo.
Muchas organizaciones tienen lo que se conoce como un "programa de documentación", el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas.
Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes elementos:
Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento.
El diseño del sistema de información administrativo.
Procedimientos para instalar el sistema de información administrativo.
Procedimientos para operar el sistema de información administrativo.
Procedimientos para mantener el sistema de información administrativo.
Importancia De La Documentación De Sistemas
La importancia de la documentación bien podría ser comparada con la importancia de la existencia de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza de Seguros está o no vigente.
La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.
Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará involucrado y no podrá moverse a otra asignación.
CERTIFICACIÓN ISO 9000
La calidad se ha convertido en el mundo globalizado de hoy, en una necesidad insoslayable para permanecer en el mercado. Por ello los sistemas de gestión de la calidad basados en las normas ISO 9000, que reflejan el consenso internacional en este tema, han cobrado una gran popularidad, y muchas organizaciones se han decidido a tomar el camino de implantarlos.
La documentación es el soporte del sistema de gestión de la calidad, pues en ella se plasman no sólo las formas de operar de la organización sino toda la información que permite el desarrollo de los procesos y la toma de decisiones.
Existen diversas metodologías para la implementación de sistemas de gestión de la calidad, y en todas sus autores coinciden en considerar a la elaboración de la documentación como una etapa importante.
El procedimiento metodológico que aquí se propone cumple el objetivo de servir como guía para implementar sistemas documentales que cumplan con los requisitos de las normas ISO 9000:2000, y pueda ser aplicado por los especialistas de calidad de cualquier organización que se enfrente a la compleja tarea de establecer un sistema de gestión de la calidad. Se ha estructurado en seis etapas, que cuentan con objetivos específicos y siguen un orden cronológico. Las tareas que se relacionan en cada etapa contribuyen al logro de los objetivos planteados y algunas pueden ser desarrolladas paralelamente, de acuerdo con la dinámica del propio proceso de implementación del sistema documental.
ETAPA 1. Determinación de las necesidades de documentación.
Objetivo: Determinar los tipos de documentos que deben existir en la organización para garantizar que los procesos se lleven a cabo bajo condiciones controladas.
Tareas:
a) Estudiar en las normas ISO 9000 los elementos de la documentación aplicables a la organización.
b) Estudiar las regulaciones específicas del sector en que se desenvuelve para determinar los documentos que deben responder al cumplimiento de requisitos legales.
c) Estudiar mapas de proceso y determinar cuáles deben ser documentados.
d) Determinar los tipos de documentos que deben existir y sus requisitos.
Etapa 2. Diagnóstico de la situación de la documentación en la organización.
Objetivo: Conocer la situación de la documentación en la organización comparando lo que existe con las necesidades determinadas en la etapa anterior.
Tareas:
a) Elaborar la guía para el diagnóstico
b) Ejecutar el diagnóstico.
c) Elaborar y presentar el informe de diagnóstico.
d) Elaborar el plan de acciones correctivas para eliminar no conformidades en la documentación existente.
Etapa 3.Diseño del sistema documental.
Objetivo: Establecer todos los elementos necesarios para la elaboración del Sistema Documental.
Tareas:
a) Definir la jerarquía de la documentación.
b) Definir estructura y formato del Manual de Calidad.
c) Determinar los procesos de la documentación.
d) Establecer el flujo de la documentación.
e) Confeccionar el plan de elaboración de documentos
f) Planificar la capacitación del personal implicado.
Etapa 4. Elaboración de los documentos.
Objetivo: Elaborar, revisar y aprobar todos los documentos a cada nivel.
Tareas:
a) Capacitar al personal implicado.
b) Elaborar los procedimientos generales.
c) Elaborar el Manual de Calidad.
d) Elaborar otros documentos de acuerdo al plan trazado en la etapa anterior.
e) Revisar y aprobar los documentos por parte del personal autorizado.
Etapa 5. Implantación del sistema documental.
Objetivo: Poner en práctica lo establecido en los documentos elaborados.
Tareas:
a) Definir el cronograma de implantación.
b) Distribuir la documentación a todos los implicados.
c) Determinar las necesidades de capacitación y actualizar el plan de capacitación.
d) Poner en práctica lo establecido en los documentos.
e) Recopilar evidencia documentada de lo anterior.
Etapa 6. Mantenimiento y mejora del sistema documental.
Objetivo: Mantener la adecuación del sistema a las necesidades de la organización a través de la mejora continúa.
Tareas:
a) Realizar auditorías internas para identificar oportunidades de mejora.
b) Implementar acciones correctivas y preventivas tendientes a eliminar no conformidades en la documentación.
En la etapa de diseño del sistema documental es donde se materializa en mayor medida la naturaleza sistémica de la gestión de la documentación. Al determinar cuáles son los procesos que la conforman y los flujos de la documentación, no se hace otra cosa que planificar el funcionamiento del sistema. El resto del ciclo de gestión (implementación, control y mejora) se manifiesta en las etapas siguientes.
Es importante en la etapa de diseño asignarle a los documentos de procedencia externa un lugar en la jerarquía de la documentación, y luego garantizar el control de estos documentos a través de las demás etapas. Aunque este procedimiento es aplicable a cualquier organización, aquellas que cuenten con la tecnología adecuada y soporten su sistema documental en un sistema informático, obtendrán resultados superiores, fundamentalmente en las etapas 5 y 6.
La aplicación del procedimiento requiere de una buena dosis de sentido común para no convertir la documentación en burocracia, y evitar que el sistema se convierta en un elemento que complique los procesos fundamentales.
Podemos concluir que:
El procedimiento metodológico propuesto constituye una guía para implementar un sistema documental acorde con las normas ISO 9000:2000 que da respuesta a la necesidad de las organizaciones que se enfrentan a esta tarea.
La aplicación del procedimiento permite trascender la simple elaboración de documentos y convertir el sistema documental en una herramienta para la gestión de la calidad.
Beneficios:
Mejor diseño del producto.
Mejor calidad del producto.
Reducción de desechos, rectificaciones y quejas de los clientes.
Eficaz utilización de mano de obra, máquinas y materiales (productividad).
Eliminación de cuellos de botella,
Creación de un clima de trabajo distendido.
Creación de una conciencia respecto a la calidad y mayor satisfacción de clientes internos, mejorando la cultura de la calidad de la organización.
Confianza entre los clientes.
Mejora la imagen y credibilidad de la empresa.
La documentación es el soporte del sistema de gestión de la calidad, pues en ella se plasman no sólo las formas de operar de la organización sino toda la información que permite el desarrollo de los procesos y la toma de decisiones.
Existen diversas metodologías para la implementación de sistemas de gestión de la calidad, y en todas sus autores coinciden en considerar a la elaboración de la documentación como una etapa importante.
El procedimiento metodológico que aquí se propone cumple el objetivo de servir como guía para implementar sistemas documentales que cumplan con los requisitos de las normas ISO 9000:2000, y pueda ser aplicado por los especialistas de calidad de cualquier organización que se enfrente a la compleja tarea de establecer un sistema de gestión de la calidad. Se ha estructurado en seis etapas, que cuentan con objetivos específicos y siguen un orden cronológico. Las tareas que se relacionan en cada etapa contribuyen al logro de los objetivos planteados y algunas pueden ser desarrolladas paralelamente, de acuerdo con la dinámica del propio proceso de implementación del sistema documental.
ETAPA 1. Determinación de las necesidades de documentación.
Objetivo: Determinar los tipos de documentos que deben existir en la organización para garantizar que los procesos se lleven a cabo bajo condiciones controladas.
Tareas:
a) Estudiar en las normas ISO 9000 los elementos de la documentación aplicables a la organización.
b) Estudiar las regulaciones específicas del sector en que se desenvuelve para determinar los documentos que deben responder al cumplimiento de requisitos legales.
c) Estudiar mapas de proceso y determinar cuáles deben ser documentados.
d) Determinar los tipos de documentos que deben existir y sus requisitos.
Etapa 2. Diagnóstico de la situación de la documentación en la organización.
Objetivo: Conocer la situación de la documentación en la organización comparando lo que existe con las necesidades determinadas en la etapa anterior.
Tareas:
a) Elaborar la guía para el diagnóstico
b) Ejecutar el diagnóstico.
c) Elaborar y presentar el informe de diagnóstico.
d) Elaborar el plan de acciones correctivas para eliminar no conformidades en la documentación existente.
Etapa 3.Diseño del sistema documental.
Objetivo: Establecer todos los elementos necesarios para la elaboración del Sistema Documental.
Tareas:
a) Definir la jerarquía de la documentación.
b) Definir estructura y formato del Manual de Calidad.
c) Determinar los procesos de la documentación.
d) Establecer el flujo de la documentación.
e) Confeccionar el plan de elaboración de documentos
f) Planificar la capacitación del personal implicado.
Etapa 4. Elaboración de los documentos.
Objetivo: Elaborar, revisar y aprobar todos los documentos a cada nivel.
Tareas:
a) Capacitar al personal implicado.
b) Elaborar los procedimientos generales.
c) Elaborar el Manual de Calidad.
d) Elaborar otros documentos de acuerdo al plan trazado en la etapa anterior.
e) Revisar y aprobar los documentos por parte del personal autorizado.
Etapa 5. Implantación del sistema documental.
Objetivo: Poner en práctica lo establecido en los documentos elaborados.
Tareas:
a) Definir el cronograma de implantación.
b) Distribuir la documentación a todos los implicados.
c) Determinar las necesidades de capacitación y actualizar el plan de capacitación.
d) Poner en práctica lo establecido en los documentos.
e) Recopilar evidencia documentada de lo anterior.
Etapa 6. Mantenimiento y mejora del sistema documental.
Objetivo: Mantener la adecuación del sistema a las necesidades de la organización a través de la mejora continúa.
Tareas:
a) Realizar auditorías internas para identificar oportunidades de mejora.
b) Implementar acciones correctivas y preventivas tendientes a eliminar no conformidades en la documentación.
En la etapa de diseño del sistema documental es donde se materializa en mayor medida la naturaleza sistémica de la gestión de la documentación. Al determinar cuáles son los procesos que la conforman y los flujos de la documentación, no se hace otra cosa que planificar el funcionamiento del sistema. El resto del ciclo de gestión (implementación, control y mejora) se manifiesta en las etapas siguientes.
Es importante en la etapa de diseño asignarle a los documentos de procedencia externa un lugar en la jerarquía de la documentación, y luego garantizar el control de estos documentos a través de las demás etapas. Aunque este procedimiento es aplicable a cualquier organización, aquellas que cuenten con la tecnología adecuada y soporten su sistema documental en un sistema informático, obtendrán resultados superiores, fundamentalmente en las etapas 5 y 6.
La aplicación del procedimiento requiere de una buena dosis de sentido común para no convertir la documentación en burocracia, y evitar que el sistema se convierta en un elemento que complique los procesos fundamentales.
Podemos concluir que:
El procedimiento metodológico propuesto constituye una guía para implementar un sistema documental acorde con las normas ISO 9000:2000 que da respuesta a la necesidad de las organizaciones que se enfrentan a esta tarea.
La aplicación del procedimiento permite trascender la simple elaboración de documentos y convertir el sistema documental en una herramienta para la gestión de la calidad.
Beneficios:
Mejor diseño del producto.
Mejor calidad del producto.
Reducción de desechos, rectificaciones y quejas de los clientes.
Eficaz utilización de mano de obra, máquinas y materiales (productividad).
Eliminación de cuellos de botella,
Creación de un clima de trabajo distendido.
Creación de una conciencia respecto a la calidad y mayor satisfacción de clientes internos, mejorando la cultura de la calidad de la organización.
Confianza entre los clientes.
Mejora la imagen y credibilidad de la empresa.
LA IMPORTANCIA DE LA DOCUMENTACIÓN EN ISO
Cuando se inicia un proceso como el de ISO 9000, no siempre se tiene conciencia de la importancia para la empresa, de desarrollar documentos de trabajo, no obstante los problemas cotidianos son similares a los más abajo referidos.
Uno de los problemas mayores en las empresas, se da cuando las personas hacen las cosas de distinta manera sin seguir una práctica establecida como forma única, consecuencia de ello son los resultados obtenidos, totalmente distintos de una persona a otra, de un departamento a otro o de una planta a otra.
Muchos de los usuales compradores de "hamburguesas" en alguna de las tiendas de comida rápida, confían en recibir invariablemente un mismo tipo de producto, un mismo servicio y hasta una misma sonrisa. Esta uniformidad únicamente se logra si las personas saben cuales cosas deben hacer (procedimiento) y el cómo hacerlo (la instrucción).
Otra dificultad generalizada se presenta cuando no se conoce con claridad las responsabilidades o bien en donde terminan las labores de una persona y en donde la pasa al compañero(a). Esto se evita con el desarrollo de la documentación partiendo del Manual de Calidad pues desde ahí se define el QUIEN HACE QUE y en los procedimientos muchas veces se incluye el CUANDO.
Por último, se encuentra la capacitación recibida cuando se ingresa a la empresa la cual hoy día, pasa de "degeneración en degeneración". Ha sido la costumbre, al iniciar un puesto el capacitar al recién llegado por medio del ocupante actual, con lo cual el conocimiento se va degenerando, pues no siempre se transmite al nuevo todo lo aprendido. El sistema de documentación permite, desde el mismo ingreso de una persona o bien traslado a una nueva función, ser capacitado en la forma originalmente establecida y considerando los cambios realizados con el tiempo en los procesos documentados.
Si bien es reconocido el éxito alcanzado por muchas empresas en el pasado, sin contar con la documentación apropiada, las exigencias del entorno (competencia) y principalmente de nuestros clientes no nos permiten entregar productos distintos a los ofrecidos o bien peores a los adquiridos la última vez.
Existen otros elementos importantes como lo es la certificación, pero es importante destacar que las empresas lo que requieren es un buen sistema de calidad, que aumente la satisfacción de sus clientes, no una certificación para colgar en la pared.
Uno de los problemas mayores en las empresas, se da cuando las personas hacen las cosas de distinta manera sin seguir una práctica establecida como forma única, consecuencia de ello son los resultados obtenidos, totalmente distintos de una persona a otra, de un departamento a otro o de una planta a otra.
Muchos de los usuales compradores de "hamburguesas" en alguna de las tiendas de comida rápida, confían en recibir invariablemente un mismo tipo de producto, un mismo servicio y hasta una misma sonrisa. Esta uniformidad únicamente se logra si las personas saben cuales cosas deben hacer (procedimiento) y el cómo hacerlo (la instrucción).
Otra dificultad generalizada se presenta cuando no se conoce con claridad las responsabilidades o bien en donde terminan las labores de una persona y en donde la pasa al compañero(a). Esto se evita con el desarrollo de la documentación partiendo del Manual de Calidad pues desde ahí se define el QUIEN HACE QUE y en los procedimientos muchas veces se incluye el CUANDO.
Por último, se encuentra la capacitación recibida cuando se ingresa a la empresa la cual hoy día, pasa de "degeneración en degeneración". Ha sido la costumbre, al iniciar un puesto el capacitar al recién llegado por medio del ocupante actual, con lo cual el conocimiento se va degenerando, pues no siempre se transmite al nuevo todo lo aprendido. El sistema de documentación permite, desde el mismo ingreso de una persona o bien traslado a una nueva función, ser capacitado en la forma originalmente establecida y considerando los cambios realizados con el tiempo en los procesos documentados.
Si bien es reconocido el éxito alcanzado por muchas empresas en el pasado, sin contar con la documentación apropiada, las exigencias del entorno (competencia) y principalmente de nuestros clientes no nos permiten entregar productos distintos a los ofrecidos o bien peores a los adquiridos la última vez.
Existen otros elementos importantes como lo es la certificación, pero es importante destacar que las empresas lo que requieren es un buen sistema de calidad, que aumente la satisfacción de sus clientes, no una certificación para colgar en la pared.
Pasos para estandarizar procedimientos
Analizar y diagnosticar los procedimientos necesarios.
Definir el tema con su estándar, procedimiento y políticas.
Capacitar al personal tanto como sea necesario.
Implementar en el área de trabajo.
Evaluar el procedimiento, el estándar y al personal aplicándolo.
Aplicar un estándar puede llevar tiempo y requiere de un esfuerzo constante hasta que se queda establecido y funcional pero vale la pena en el mediano y largo plazo, sólo que no deje un estándar por siempre, revíselo y modifíquelo o modifique el procedimiento de ser necesario para que vaya a la par con el crecimiento de la empresa y su entorno.
El sistema ISO 9000 se refiere a un grupo de Normas sobre el Sistema de Calidad de cualquier tipo de empresa, sea esta una industria, un banco o una oficina del gobierno, pequeña o grande. ISO, en otros términos significa hacer las cosas de una misma manera indiferentemente de la persona encargada de ejecutar el proceso, pues ésta debe hacerlo tal y como se establece en los documentos de trabajo establecidos o en la capacitación brindada.
Pero además ISO significa para las empresas el ordenarse de una manera lógica, siguiendo las diferentes etapas desde el diseño del producto o servicio, su venta, la compra de materiales, la ejecución del proceso, el almacenaje y la entrega al cliente.
Adicionalmente las empresas documentan la forma de hacer las cosas, para siempre hacerlas de una manera idéntica, lo cual significa entregar productos y servicios idénticos, indiferentemente del lugar en donde se ubiquen las diferentes plantas o de las personas encargadas de elaborarlos, tal como podemos observarlo en las cadenas de comidas rápidas internacionales. Hay que aclarar que el hacer las cosas de manera idéntica no implica que se estén haciendo correctamente las cosas correctas.
ISO sustenta las técnicas desarrolladas durante bastante tiempo por el "Mejoramiento Continuo, Kaizen" o bien la "Reingeniería" pues obliga a documentar los cambios en los procesos de manera de no perder el aporte tan valioso brindado por los colaboradores de la empresa.
Otro punto que refuerza el que realmente se hagan las cosas tal y como se escribe, se logra por medio de las Auditorías Internas, en donde el mismo personal debidamente capacitado y con conocimientos sobre los procesos, verifica de una forma objetiva e independiente si realmente lo que se establece en la documentación es lo que se realiza. Un proceso puede estar documentado, y no necesariamente escrito. Si esto no es así se emiten no conformidades detectadas en el sistema.
Cada gerencia como responsable de su área, da seguimiento a todas las no conformidades por medio de acciones correctivas o preventivas verificando tanto su implementación como la efectividad de los cambios realizados y si éstos realmente han logrado el resultado esperado.
Definir el tema con su estándar, procedimiento y políticas.
Capacitar al personal tanto como sea necesario.
Implementar en el área de trabajo.
Evaluar el procedimiento, el estándar y al personal aplicándolo.
Aplicar un estándar puede llevar tiempo y requiere de un esfuerzo constante hasta que se queda establecido y funcional pero vale la pena en el mediano y largo plazo, sólo que no deje un estándar por siempre, revíselo y modifíquelo o modifique el procedimiento de ser necesario para que vaya a la par con el crecimiento de la empresa y su entorno.
El sistema ISO 9000 se refiere a un grupo de Normas sobre el Sistema de Calidad de cualquier tipo de empresa, sea esta una industria, un banco o una oficina del gobierno, pequeña o grande. ISO, en otros términos significa hacer las cosas de una misma manera indiferentemente de la persona encargada de ejecutar el proceso, pues ésta debe hacerlo tal y como se establece en los documentos de trabajo establecidos o en la capacitación brindada.
Pero además ISO significa para las empresas el ordenarse de una manera lógica, siguiendo las diferentes etapas desde el diseño del producto o servicio, su venta, la compra de materiales, la ejecución del proceso, el almacenaje y la entrega al cliente.
Adicionalmente las empresas documentan la forma de hacer las cosas, para siempre hacerlas de una manera idéntica, lo cual significa entregar productos y servicios idénticos, indiferentemente del lugar en donde se ubiquen las diferentes plantas o de las personas encargadas de elaborarlos, tal como podemos observarlo en las cadenas de comidas rápidas internacionales. Hay que aclarar que el hacer las cosas de manera idéntica no implica que se estén haciendo correctamente las cosas correctas.
ISO sustenta las técnicas desarrolladas durante bastante tiempo por el "Mejoramiento Continuo, Kaizen" o bien la "Reingeniería" pues obliga a documentar los cambios en los procesos de manera de no perder el aporte tan valioso brindado por los colaboradores de la empresa.
Otro punto que refuerza el que realmente se hagan las cosas tal y como se escribe, se logra por medio de las Auditorías Internas, en donde el mismo personal debidamente capacitado y con conocimientos sobre los procesos, verifica de una forma objetiva e independiente si realmente lo que se establece en la documentación es lo que se realiza. Un proceso puede estar documentado, y no necesariamente escrito. Si esto no es así se emiten no conformidades detectadas en el sistema.
Cada gerencia como responsable de su área, da seguimiento a todas las no conformidades por medio de acciones correctivas o preventivas verificando tanto su implementación como la efectividad de los cambios realizados y si éstos realmente han logrado el resultado esperado.
sábado, 9 de enero de 2010
La Estandarización
Un estándar es el requisito mínimo que debe cumplir un procedimiento, de acuerdo a la definición y objetivo que haya propuesto en su empresa. Lo cual significa en forma práctica lograr que todo el personal realice el mismo procedimiento en la misma forma para lograr el mismo resultado. Para que un estándar pueda ser aplicado debe llevar una serie de pasos muy específicos y claros, cuyo conjunto denominamos procedimiento. El procedimiento está definido por tareas específicas que buscan cumplir un cierto objetivo y que seguido paso a paso repercutirá en el resultado deseado independientemente de quién lo realice. Esto aplica también para los estandares para la documentación de cualquier sistema.
Si se logra estandarizar mediante procedimientos las actividades de la empresa se conseguirá disminuir tiempos y tener una imagen sólida de empresa eficiente; pero lograr esto requiere de un poco de tiempo y paciencia.
Se debe empezar por analizar y diagnosticar cuáles son los procedimientos necesarios para la operación, qué funciona y qué no funciona actualmente, qué procedimientos existen y cuáles no existen tanto en forma operativa como en forma escrita y cuáles son las prioridades. El siguiente paso es definir los temas que serán convertidos en procedimientos con su estándar específico. Se debe continuar con una capacitación para todo el personal para que comprendan el concepto y las ventajas de estandarizar las operaciones, seguido del entrenamiento de los temas específicos mediante enseñanza teórico-práctica donde los participantes deben realizar el procedimiento para entenderlo perfectamente. Por último se debe evaluar en forma periódica para asegurar la calidad del servicio y detectar posibles malos entendidos o actitudes contrarias al procedimiento o hasta errores de planeación en el procedimiento, para poder tomar acción y corregir.
La estandarización es un proceso de mejora continua en el que los clientes percibirán un alto grado de profesionalismo y se podrá obtener un mejor control de las acciones, además de poder dar congruencia a una imagen profesional con un servicio o producto del mismo nivel.
Otros conceptos de Estandarizacion:
Significa que los símbolos convencionales se usan en todos los diagramas de flujo para prescribir el sistema y que en la documentación se usen formas estandarizadas.
Aún cuando las normas de documentación varían de una instalación a otra, es esencial que dentro de una organización, se utilice un solo método. El uso de procedimientos y documentación estandarizada proporciona la base de una comunicación clara y rápida, adiestramiento menos costoso del personal de sistemas, reducción de costos de almacenamiento, y otros.
Ventajas De La Estandarizacion
Ayuda al entrenamiento del nuevo personal dentro y fuera de la organización de Sistemas.
Es útil para cualquiera que tenga la responsabilidad del mantenimiento de los sistemas.
Ayuda a los analistas y diseñadores de sistemas en el trabajo de integración de sistemas.
Asegura que el sistema opere correctamente.
Se utilizan eficientemente los recursos que se dispongan.
Estandares Básicos De Documentación
Toda documentación que se relacione con un sistema, ya sea manual o por computadora, sencillo o complejo debe reunir los siguientes requisitos básicos:
Debe ser rotulada con claridad y bien organizada, con secciones claramente indicadas, almacenarlas en carpetas e índice.
Los diagramas deberán ser claros, no aglomerados y la escritura manuscrita deberá ser legible.
La documentación deberá ser completa.
Se incluirá una leyenda o explicación de los términos utilizados.
La documentación siempre se conserva actualizada.
Si se logra estandarizar mediante procedimientos las actividades de la empresa se conseguirá disminuir tiempos y tener una imagen sólida de empresa eficiente; pero lograr esto requiere de un poco de tiempo y paciencia.
Se debe empezar por analizar y diagnosticar cuáles son los procedimientos necesarios para la operación, qué funciona y qué no funciona actualmente, qué procedimientos existen y cuáles no existen tanto en forma operativa como en forma escrita y cuáles son las prioridades. El siguiente paso es definir los temas que serán convertidos en procedimientos con su estándar específico. Se debe continuar con una capacitación para todo el personal para que comprendan el concepto y las ventajas de estandarizar las operaciones, seguido del entrenamiento de los temas específicos mediante enseñanza teórico-práctica donde los participantes deben realizar el procedimiento para entenderlo perfectamente. Por último se debe evaluar en forma periódica para asegurar la calidad del servicio y detectar posibles malos entendidos o actitudes contrarias al procedimiento o hasta errores de planeación en el procedimiento, para poder tomar acción y corregir.
La estandarización es un proceso de mejora continua en el que los clientes percibirán un alto grado de profesionalismo y se podrá obtener un mejor control de las acciones, además de poder dar congruencia a una imagen profesional con un servicio o producto del mismo nivel.
Otros conceptos de Estandarizacion:
Significa que los símbolos convencionales se usan en todos los diagramas de flujo para prescribir el sistema y que en la documentación se usen formas estandarizadas.
Aún cuando las normas de documentación varían de una instalación a otra, es esencial que dentro de una organización, se utilice un solo método. El uso de procedimientos y documentación estandarizada proporciona la base de una comunicación clara y rápida, adiestramiento menos costoso del personal de sistemas, reducción de costos de almacenamiento, y otros.
Ventajas De La Estandarizacion
Ayuda al entrenamiento del nuevo personal dentro y fuera de la organización de Sistemas.
Es útil para cualquiera que tenga la responsabilidad del mantenimiento de los sistemas.
Ayuda a los analistas y diseñadores de sistemas en el trabajo de integración de sistemas.
Asegura que el sistema opere correctamente.
Se utilizan eficientemente los recursos que se dispongan.
Estandares Básicos De Documentación
Toda documentación que se relacione con un sistema, ya sea manual o por computadora, sencillo o complejo debe reunir los siguientes requisitos básicos:
Debe ser rotulada con claridad y bien organizada, con secciones claramente indicadas, almacenarlas en carpetas e índice.
Los diagramas deberán ser claros, no aglomerados y la escritura manuscrita deberá ser legible.
La documentación deberá ser completa.
Se incluirá una leyenda o explicación de los términos utilizados.
La documentación siempre se conserva actualizada.
jueves, 31 de diciembre de 2009
N O R M A: ISO 15836 para catalogar documentos
Para la documentación es muy importante la estandarización. Es por ello que buscamos ahondar en el tema de las normas ISO y Dublin Core para catalogar con metadatos cualquier documento. Como veremos esto tiene por fin último permitir y facilitar la busqueda y acceso a un documento. La información crece de manera exponencial en todo el mundo y en las organizaciones públicas o privadas. También crecen los medios digitales para almacenarla, pero su administración es el problema. También es un problema como buscarla, valorarla y accederla. Para ello son los sistemas de documentación. Desde nuestra visión como grupo de investigación UNESRísta queremos aportar estos conceptos de última generación tecnológica a todo el curso. Allí vamos con los estándares.
Antecedentes
ISO (la Organización Internacional de Normalización) es una federación mundial de organismos nacionales de normalización (organismos miembros de ISO). El trabajo de preparación de normas internacionales normalmente se realiza a través de los comités técnicos de ISO. Todo organismo miembro interesado en una materia para la cual existe un comité técnico tiene el derecho a estar representado en dicho comité. Las organizaciones internacionales, públicas y privadas, que están en contacto con ISO también participan es este trabajo. ISO colabora estrechamente con la Comisión Internacional Electrotécnica (CIE) en materia de normalización electrotécnica.
Las Normas Internacionales se redactan de acuerdo a las normas establecidas en
la parte 2 de las Directrices ISO/IEC. La principal tarea de los comités técnicos es la preparación de Normas Internacionales.
Los proyectos de Normas Internacionales adoptados por los comités técnicos se envían a los organismos miembros para que se proceda a su votación. Para su publicación como Norma Internacional se requiere, al menos, la aprobación del 75%
de los organismos que participan en la votación. Cabe señalar la posibilidad de que alguno de los elementos de este documento
pueda estar sujeto a derechos de patente. ISO no asume responsabilidad alguna en la identificación de cualquier derecho de patente que afecte a algún elemento o a la totalidad de esta norma.
La Norma ISO 15836 fue preparada por la National Information Standards Organization (como ANSI/NISO Z39 85-2001) y adoptada por el Comité Técnico.
Introducción
La Iniciativa de Metadatos Dublin Core (DCMI) comenzó en 1995 con la convocatoria de un taller de trabajo en Dublin, Ohio, que reunió a bibliotecarios, investigadores sobre la biblioteca digital, distribuidores de contenidos y expertos en marcado
textual para mejorar la elaboración de estándares y normas relacionadas con la recuperación de información aplicables a los recursos. El Dublin Core original surgió como un pequeño conjunto de descriptores que rápidamente suscitó el interés
general de una amplia variedad de proveedores de información de los sectores de las artes, las ciencias, la educación, el ámbito empresarial y las administraciones públicas.
Desde que se celebró el primer taller se ha generado un interés cada vez mayor por las descripciones de recursos, que sean fáciles de crear y que casi cualquiera pueda entender. El potencial para aumentar la visibilidad de los recursos en una colección entre sectores y dominios temáticos, y de hacerlo a un bajo coste, está cobrando un interés generalizado. Aquellos servicios que necesitan descripciones ricas desde un punto de vista semántico podrán continuar proporcionándolas, pero podrán ser objeto de una recuperación de información interdisciplinar gracias a que proporcionan también descripciones comprensibles de manera universal, comunes a distintas disciplinas. En este contexto, resulta apropiada la metáfora del «turista digital». Los viajeros en Internet que buscan información en disciplinas que les son ajenas pueden utilizar el vocabulario restringido del Dublin Core para obtener la ayuda básica en un idioma que pueden entender. El acceso completo a la cultura y a sus servicios requiere todavía el dominio de vocabularios locales y del contexto, pero un conjunto de datos sencillos codificados en Dublin Core puede dirigir la atención del «turista» a un portal de información que de otra manera podría haberle pasado desapercibido.
El interés por la localización de información interdisciplinar suscitó una participación creciente en la serie de talleres de la DCMI que se celebraron posteriormente. El conjunto de elementos de metadatos Dublin Core, que se describe aquí, es un conjunto de 15 descriptores, que resultaron de este esfuerzo por alcanzar un consenso interdisciplinar e internacional. En la actualidad, el Dublin Core se ha traducido a más de 20 idiomas, y ha sido adoptado por el CEN/ISSS (Comité Europeo de Normalización/ Sistema de Normalización para la Sociedad de la Información) está documentado en dos RFC (Request For Comments). También tiene carácter oficial dentro del Consorcio de la WWW y de la norma ISO 23950. Los metadatos Dublin Core fueron aprobados como norma nacional en USA (ANSI/NISO Z39.85), formalmente aceptados por más de siete gobiernos para fomentar la recuperación de información gubernamental en formato electrónico, y adoptados por varias agencias supranacionales como la Organización Mundial de a Salud (OMS/WHO). Muchas de las iniciativas de metadatos específicos de una comunidad, como bibliotecas, archivos, aplicaciones educativas o gubernamentales utilizan como base de sus modelos de metadatos el Dublin Core.
El Dublin Core no pretende desplazar a otros estándares de metadatos. Más bien, su intención es coexistir, muchas veces, en la misma descripción de un recurso, con estándares de metadatos que propongan otra semántica. Es muy previsible que los
registros descriptivos contengan una combinación de elementos extraídos de diferentes estándares de metadatos, tanto simples como complejos. Se pueden encontrar ejemplos de este tipo de combinación, así como de la codificación HTML del Dublin Core, en la RFC 2731 [RFC 2731]. La sencillez del Dublin Core puede ser tanto una fortaleza como una debilidad.
La simplicidad reduce el coste de la creación de metadatos y fomenta la interoperabilidad.
Por otro lado, la sencillez de Dublin Core no se ajusta a la riqueza funcional y semántica que proporcionan esquemas de metadatos complejos. De hecho, el Dublin Core renuncia a la riqueza por una visibilidad generalizada. El diseño del Dublin Core compensa esta pérdida fomentando la utilización de esquemas de metadatos más ricos combinados con el propio Dublin Core. Se pueden crear equivalencias entre esos esquemas más sofisticados y el Dublin Core para facilitar la exportación y las búsquedas entre diferentes sistemas. A la inversa, los registros del Dublin Core simple se pueden usar como un punto de partida para la creación de
descripciones más complejas.
El conjunto de elementos de metadatos Dublin Core
1. Objeto y alcance
El conjunto de elementos de metadatos Dublin Core es una norma para la descripción de recursos de información de distintos dominios informativos. En este contexto, un recurso de información se define como cualquier cosa que tiene identidad. Esta es la definición utilizada en la RFC 2396, Identificadores Uniformes de Recursos (URI): Sintaxis Genérica, de Tim Berners-Lee y otros. Para las aplicaciones del Dublin Core, un recurso será normalmente un documento electrónico. Esta norma se refiere sólo al conjunto de elementos, que se utilizan generalmente en el contexto de una aplicación o proyecto específico. Los requisitos y políticas locales o específicas de una comunidad informativa pueden implicar restricciones, reglas o interpretaciones adicionales. No es propósito de esta norma definir los criterios detallados relativos a la aplicación del conjunto de elementos dentro de proyectos y aplicaciones específicas.
2. Normas para consulta
Los siguientes documentos normativos contienen disposiciones que, mediante referencia en este texto, forman disposiciones de este estándar internacional. Para referencias fechadas, modificaciones posteriores, o revisiones de la misma, ninguna de éstas se aplica. Sin embargo, se recomienda a los interesados, en acuerdos basados en este estándar internacional, que analicen la posibilidad de aplicar las versiones más recientes de los documentos normativos incluidos en la lista inferior. Para referencias sin fecha, se aplica la última edición de los documentos referidos. Los miembros de ISOC y de IEC mantienen registros de los estándares internacionales actualmente válidos.La abreviatura entre corchetes al inicio de cada cita indica cómo se cita el documentoen el texto del estándar.
[DCT] DCMI Type Vocabulary DCMI Recommendation, 11 July 2000.
http://dublincore.org/documents/dcmi-type-vocabulary/
en español: http://es.dublincore.org/documents/dcmi-type-vocabulary/
[ISO3166] ISO 3166 - Codes for the representation of names of countries and
their subdivisions.
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-codelists/
index.html
[ISO639] ISO 639-2 – Codes for the representation of names of languages.Part
2: Alpha-3 code (ISO 639-2:1998)
http://www.loc.gov/standards/iso639-2/langhome.html
[MIME] Internet Media Types.
http://www.iana.org/assignments/media-types/
[RFC3066] Tags for the identification of Languages, Internet RFC 3066.
http://www.ietf.org/rfc/rfc3066.txt
[RFC2396] Uniform Resource Identifiers (URI): Generic Sintax, Internet RFC
2396.
http://www.ietf.org/rfc/rfc2396.txt
[RFC2413] Dublin Core Metadata for Resource Discovery, Internet RFC
2413.
http://www.ietf.org/rfc/rfc2413.txt
[RFC2731] Encoding Dublin Core Metadata in HTML, Internet RFC 2731.
http://www.ietf.org/rfc/rfc2731.txt
NORMAS
REV. ESP. DOC. CIENT., 29, 2, ABRIL-JUNIO, 287-296, 2006. ISSN 0210-0614 291
[TGN] Getty Thesaurus of Geographic Names.
http://www.getty.edu/research/tools/vocabulary/tgn/index.html
[W3CDTF] Date and Time Formats. W3C Note.
http://www.w3.org/TR/NOTE-datetime
[XML] Extensible Markup Language
http://www.w3.org/TR/REC-xml
3. Definiciones
DCMI — Dublin Core Metadata Initiative. La agencia encargada del mantenimiento del Dublin Core
Recurso de información — «Algo que tiene identidad» (la misma definición que en la RFC 2396) Ciclo de vida de un recurso de información— Una secuencia de hechos que marcan el desarrollo y el uso de un recurso de información. Algunos ejemplos de hechos en un ciclo de vida son: La concepción de una invención, la creación de un borrador, la revisión de un artículo, la publicación de un libro, el proceso de adquisición en una biblioteca, la trascripción a disco magnético, la migración a un sistema de almacenamiento óptico, una traducción al inglés, y la versión de un nuevo trabajo (p. ej. una película).
4. El conjunto de elementos
En la descripción de elementos que se hace a continuación, cada uno de ellos tiene una etiqueta descriptiva, cuya finalidad es dar a conocer una semántica común que facilite la comprensión del elemento, y un nombre constituido por una única palabra, entendible por máquina, cuyo objetivo es simplificar la descripción sintáctica de los elementos para los esquemas de codificación.
Aunque en algunos entornos, como HTML, no hay diferenciación entre mayúsculas y minúsculas, se recomienda siempre como práctica más recomendable atenerse a las convenciones de uso de mayúscula/minúscula en los nombres de los elementos que
se proponen a continuación, para evitar problemas en el caso de que los metadatos se extraigan o se conviertan posteriormente a un entorno donde sí se diferencian mayúsculas y minúsculas como puede ser XML (Lenguaje de Marcado Extensible [XML].
Cada elemento es opcional y repetible. Los elementos de metadatos pueden aparecer en cualquier orden. La ordenación de múltiples ocurrencias del mismo elemento (por ej. Creator) puede tener algún significado intencionado por el que proporciona
el recurso, pero no se puede garantizar que el orden se mantenga en todos los sistemas.
Para promover la interoperabilidad global, algunas de las descripciones de los elementos sugieren un vocabulario controlado para la asignación de valores. Asimismo se asume que se desarrollarán otros vocabularios controlados para conseguir la interoperabilidad dentro de algunos dominios informativos específicos o locales.
5. Elementos
Nombre del elemento: Title
Etiqueta: Título
Definición: Un nombre dado al recurso.
Comentario: Normalmente, el título será el nombre por el que se conoce formalmente el recurso.
Nombre del elemento: Creator
Etiqueta: Creador
Definición: Una entidad que es responsable principal de la elaboración del contenido del recurso.
Comentario: Ejemplos de creador de un recurso pueden ser, una persona, una organización o un servicio. Normalmente este campo debería utilizarse para indicar la entidad.
Nombre del elemento: Subject
Etiqueta: Materias y palabras clave
Definición: Un tema del contenido del recurso
Comentario: Normalmente, la materia se expresará con palabras clave, descriptores o códigos de clasificación que representen el tema del recurso. La práctica más recomendable es seleccionar estos valores de un vocabulario controlado o de un esquema formal de clasificación.
Nombre del elemento: Description
Etiqueta: Descripción
Definición: Una descripción del contenido del recurso
Comentario: Aunque no se limitan a estos, algunos ejemplos de descripción son un resumen, un índice de contenido, una explicación en texto libre o una referencia a una representación gráfica del contenido.
Nombre del elemento: Publisher
Etiqueta: Editor
Definición: Una entidad responsable de que el recurso esté disponible.
Comentario: Ejemplos de editor son: una persona, una organización o un servicio.
Normalmente el nombre de un editor debería utilizarse para indicar la entidad.
Nombre del elemento: Contributor
Etiqueta: Colaborador
Definición: Una entidad responsable de realizar contribuciones al contenido de
un recurso.
Comentario: Ejemplos de colaborador pueden ser: una persona, una organización o un servicio. Normalmente el nombre de un colaborador debe utilizarse para indicar la entidad.
Nombre del elemento: Date
Etiqueta: Fecha
Definición: Una fecha de un hecho relativo al ciclo de vida del recurso.
Comentario: Normalmente la fecha se asociará con la creación o la disponibilidad del recurso. La práctica más recomendable para codificar el valor de la fecha se define en el perfil ISO 8601 [W3CDTF] que incluye fechas de la forma AAAAMM-
DD.
Nombre del elemento: Type
Etiqueta: Tipo de recurso
Definición: La naturaleza o género del contenido del recurso.
Comentario: El tipo se refiere a términos que describen categorías generales,
funciones, géneros o niveles de agregación para el contenido. La práctica más recomendable
en este sentido es seleccionar un valor de un vocabulario controlado (por ejemplo, del DCMI Type Vocabulary [DCT1]). Para describir la manifestación física o digital del recurso debe emplearse el elemento Format.
Nombre del elemento: Formato
Etiqueta: Formato
Definición: La manifestación física o digital del recurso.
Comentario: Normalmente el formato se referirá a los tipos de medios o dimensiones de un recurso. El formato puede usarse para identificar el software, hardware u otros equipamientos necesarios para visualizar el recurso u operar con él. Ejemplos de dimensiones pueden ser el tamaño o la duración. La práctica más recomendable en este caso es seleccionar el valor de un vocabulario controlado (por ejemplo,la lista de Internet Media Types [MIME]).
Nombre del elemento: Identifier
Etiqueta: Identificador del recurso
Definición: Una referencia inequívoca al recurso dentro de un contexto determinado.
Comentario: La práctica más recomendable es identificar el recurso por medio de una cadena de caracteres o por un número conforme a un sistema formal de identificación. Algunos sistemas identificación formal de recursos son, entre otros, el
Uniform Resource Identifier (URI) que incluye el Localizador Uniforme de RecurNORMAS 294 REV. ESP. DOC. CIENT., 29, 2, ABRIL-JUNIO, 287-296, 2006. ISSN 0210-0614 sos (URL), el Digital Object Identifier (DOI) y el International Standard Book Number (ISBN).
Nombre del elemento: Source
Etiqueta: Fuente
Definición: Una referencia a un recurso del cual deriva el que se está describiendo.
Comentario: El recurso que se está describiendo puede derivar, en todo o en parte, de un recurso fuente. La práctica más recomendable en este caso es identificar el recurso referenciado por medio de una cadena de caracteres o número conforme
con un sistema de identificación formal.
Nombre del elemento: Language
Etiqueta: Idioma
Definición: Un idioma del contenido intelectual del recurso.
Comentario: La práctica más recomendable es usar la RFC 3066 [RFC3066] que, en conjunción con la norma ISO 639 [ISO639], define etiquetas de dos y tres letras para identificar el idioma principal, con subetiquetas opcionales. Algunos ejemplos son: «en» o «eng» para Inglés, «akk» para el acadio, y «en-GB» para el inglés utilizado en el Reino Unido.
Nombre del elemento: Relation
Etiqueta: Relación
Definición: Una referencia a un recurso relacionado.
Comentario: La práctica más recomendable es identificar los recursos referenciados por medio de una cadena de caracteres o número conforme a un sistema de identificación formal.
Nombre del elemento: Coverage
Etiqueta: Cobertura
Definición: La extensión o el alcance del contenido del recurso.
Comentario: Normalmente la cobertura incluirá la localización espacial (un nombre de un lugar o unas coordenadas geográficas), el periodo temporal (una expresión que identifica un período, fecha o rango de fecha) o la jurisdicción (por ejemplo una denominación de una entidad administrativa). La práctica más recomendable es seleccionar un valor de un vocabulario controlado (por ejemplo, del
Thesaurus of Geographical Names [TGN]) y usar, cuando sea oportuno, nombres de periodos de tiempo o de lugares, mejor que identificadores numéricos, como conjuntosde coordenadas o rangos de fecha.
Nombre del elemento: Rights
Etiqueta: Derechos
Definición: Información sobre los derechos contenidos en y sobre el recurso.
Comentario: Normalmente los derechos contendrán una declaración de gestión de derechos para el recurso, o una referencia a un servicio que proporcione dicha información. La información sobre los derechos normalmente abarca los derechos de Propiedad Intelectual (PI), derechos de autor y otros derechos relacionados con la propiedad. Si no consta el elemento de derechos no se deben hacer asunciones sobre ningún derecho contenido en el recurso o entorno a él.
Anexo A:
Información complementaria
(Este anexo no forma parte del Estándar Nacional Americano sobre el Conjunto de Elementos de Metadatos Dublin Core, ANSI/NISO Z39.85-2001. Se incluye solamente a nivel informativo). Se puede encontrar información complementaria sobre el Conjunto de Metadatos Dublin Core en el URL http://dublincore.org e información en español sobre esta norma en el mirror de la iniciativa en este idioma en el URL http://es.dublincore.org Ambos sitios web tienen información (en inglés y español, respectivamente) sobre los talleres, informes, documentos de los grupos de trabajo, proyectos y nuevos desarrollos relacionados con la Iniciativa de Metadatos Dublin Core (DCMI).
Anexo B:
Agencia responsable del mantenimiento de este estándar
(Este anexo no forma parte de Estándar Nacional Americano Conjunto de Elementos de Metadatos Dublin Core, ANSI/NISO Z39.85-2001. Se incluye solamente a nivel informativo). La Iniciativa de Metadatos Dublin Core es la responsable del desarrollo, Normalización y promoción del conjunto de elementos de metadatos Dublin Core. Se puede encontrar información sobre la DCMI en el URL http://dublincore.org.
N O R M A S
REVISTA ESPAÑOLA DE DOCUMENTACIÓN CIENTÍFICA
29, 2, ABRIL-JUNIO, 287-296, 2006
ISSN 0210-0614
Antecedentes
ISO (la Organización Internacional de Normalización) es una federación mundial de organismos nacionales de normalización (organismos miembros de ISO). El trabajo de preparación de normas internacionales normalmente se realiza a través de los comités técnicos de ISO. Todo organismo miembro interesado en una materia para la cual existe un comité técnico tiene el derecho a estar representado en dicho comité. Las organizaciones internacionales, públicas y privadas, que están en contacto con ISO también participan es este trabajo. ISO colabora estrechamente con la Comisión Internacional Electrotécnica (CIE) en materia de normalización electrotécnica.
Las Normas Internacionales se redactan de acuerdo a las normas establecidas en
la parte 2 de las Directrices ISO/IEC. La principal tarea de los comités técnicos es la preparación de Normas Internacionales.
Los proyectos de Normas Internacionales adoptados por los comités técnicos se envían a los organismos miembros para que se proceda a su votación. Para su publicación como Norma Internacional se requiere, al menos, la aprobación del 75%
de los organismos que participan en la votación. Cabe señalar la posibilidad de que alguno de los elementos de este documento
pueda estar sujeto a derechos de patente. ISO no asume responsabilidad alguna en la identificación de cualquier derecho de patente que afecte a algún elemento o a la totalidad de esta norma.
La Norma ISO 15836 fue preparada por la National Information Standards Organization (como ANSI/NISO Z39 85-2001) y adoptada por el Comité Técnico.
Introducción
La Iniciativa de Metadatos Dublin Core (DCMI) comenzó en 1995 con la convocatoria de un taller de trabajo en Dublin, Ohio, que reunió a bibliotecarios, investigadores sobre la biblioteca digital, distribuidores de contenidos y expertos en marcado
textual para mejorar la elaboración de estándares y normas relacionadas con la recuperación de información aplicables a los recursos. El Dublin Core original surgió como un pequeño conjunto de descriptores que rápidamente suscitó el interés
general de una amplia variedad de proveedores de información de los sectores de las artes, las ciencias, la educación, el ámbito empresarial y las administraciones públicas.
Desde que se celebró el primer taller se ha generado un interés cada vez mayor por las descripciones de recursos, que sean fáciles de crear y que casi cualquiera pueda entender. El potencial para aumentar la visibilidad de los recursos en una colección entre sectores y dominios temáticos, y de hacerlo a un bajo coste, está cobrando un interés generalizado. Aquellos servicios que necesitan descripciones ricas desde un punto de vista semántico podrán continuar proporcionándolas, pero podrán ser objeto de una recuperación de información interdisciplinar gracias a que proporcionan también descripciones comprensibles de manera universal, comunes a distintas disciplinas. En este contexto, resulta apropiada la metáfora del «turista digital». Los viajeros en Internet que buscan información en disciplinas que les son ajenas pueden utilizar el vocabulario restringido del Dublin Core para obtener la ayuda básica en un idioma que pueden entender. El acceso completo a la cultura y a sus servicios requiere todavía el dominio de vocabularios locales y del contexto, pero un conjunto de datos sencillos codificados en Dublin Core puede dirigir la atención del «turista» a un portal de información que de otra manera podría haberle pasado desapercibido.
El interés por la localización de información interdisciplinar suscitó una participación creciente en la serie de talleres de la DCMI que se celebraron posteriormente. El conjunto de elementos de metadatos Dublin Core, que se describe aquí, es un conjunto de 15 descriptores, que resultaron de este esfuerzo por alcanzar un consenso interdisciplinar e internacional. En la actualidad, el Dublin Core se ha traducido a más de 20 idiomas, y ha sido adoptado por el CEN/ISSS (Comité Europeo de Normalización/ Sistema de Normalización para la Sociedad de la Información) está documentado en dos RFC (Request For Comments). También tiene carácter oficial dentro del Consorcio de la WWW y de la norma ISO 23950. Los metadatos Dublin Core fueron aprobados como norma nacional en USA (ANSI/NISO Z39.85), formalmente aceptados por más de siete gobiernos para fomentar la recuperación de información gubernamental en formato electrónico, y adoptados por varias agencias supranacionales como la Organización Mundial de a Salud (OMS/WHO). Muchas de las iniciativas de metadatos específicos de una comunidad, como bibliotecas, archivos, aplicaciones educativas o gubernamentales utilizan como base de sus modelos de metadatos el Dublin Core.
El Dublin Core no pretende desplazar a otros estándares de metadatos. Más bien, su intención es coexistir, muchas veces, en la misma descripción de un recurso, con estándares de metadatos que propongan otra semántica. Es muy previsible que los
registros descriptivos contengan una combinación de elementos extraídos de diferentes estándares de metadatos, tanto simples como complejos. Se pueden encontrar ejemplos de este tipo de combinación, así como de la codificación HTML del Dublin Core, en la RFC 2731 [RFC 2731]. La sencillez del Dublin Core puede ser tanto una fortaleza como una debilidad.
La simplicidad reduce el coste de la creación de metadatos y fomenta la interoperabilidad.
Por otro lado, la sencillez de Dublin Core no se ajusta a la riqueza funcional y semántica que proporcionan esquemas de metadatos complejos. De hecho, el Dublin Core renuncia a la riqueza por una visibilidad generalizada. El diseño del Dublin Core compensa esta pérdida fomentando la utilización de esquemas de metadatos más ricos combinados con el propio Dublin Core. Se pueden crear equivalencias entre esos esquemas más sofisticados y el Dublin Core para facilitar la exportación y las búsquedas entre diferentes sistemas. A la inversa, los registros del Dublin Core simple se pueden usar como un punto de partida para la creación de
descripciones más complejas.
El conjunto de elementos de metadatos Dublin Core
1. Objeto y alcance
El conjunto de elementos de metadatos Dublin Core es una norma para la descripción de recursos de información de distintos dominios informativos. En este contexto, un recurso de información se define como cualquier cosa que tiene identidad. Esta es la definición utilizada en la RFC 2396, Identificadores Uniformes de Recursos (URI): Sintaxis Genérica, de Tim Berners-Lee y otros. Para las aplicaciones del Dublin Core, un recurso será normalmente un documento electrónico. Esta norma se refiere sólo al conjunto de elementos, que se utilizan generalmente en el contexto de una aplicación o proyecto específico. Los requisitos y políticas locales o específicas de una comunidad informativa pueden implicar restricciones, reglas o interpretaciones adicionales. No es propósito de esta norma definir los criterios detallados relativos a la aplicación del conjunto de elementos dentro de proyectos y aplicaciones específicas.
2. Normas para consulta
Los siguientes documentos normativos contienen disposiciones que, mediante referencia en este texto, forman disposiciones de este estándar internacional. Para referencias fechadas, modificaciones posteriores, o revisiones de la misma, ninguna de éstas se aplica. Sin embargo, se recomienda a los interesados, en acuerdos basados en este estándar internacional, que analicen la posibilidad de aplicar las versiones más recientes de los documentos normativos incluidos en la lista inferior. Para referencias sin fecha, se aplica la última edición de los documentos referidos. Los miembros de ISOC y de IEC mantienen registros de los estándares internacionales actualmente válidos.La abreviatura entre corchetes al inicio de cada cita indica cómo se cita el documentoen el texto del estándar.
[DCT] DCMI Type Vocabulary DCMI Recommendation, 11 July 2000.
http://dublincore.org/documents/dcmi-type-vocabulary/
en español: http://es.dublincore.org/documents/dcmi-type-vocabulary/
[ISO3166] ISO 3166 - Codes for the representation of names of countries and
their subdivisions.
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-codelists/
index.html
[ISO639] ISO 639-2 – Codes for the representation of names of languages.Part
2: Alpha-3 code (ISO 639-2:1998)
http://www.loc.gov/standards/iso639-2/langhome.html
[MIME] Internet Media Types.
http://www.iana.org/assignments/media-types/
[RFC3066] Tags for the identification of Languages, Internet RFC 3066.
http://www.ietf.org/rfc/rfc3066.txt
[RFC2396] Uniform Resource Identifiers (URI): Generic Sintax, Internet RFC
2396.
http://www.ietf.org/rfc/rfc2396.txt
[RFC2413] Dublin Core Metadata for Resource Discovery, Internet RFC
2413.
http://www.ietf.org/rfc/rfc2413.txt
[RFC2731] Encoding Dublin Core Metadata in HTML, Internet RFC 2731.
http://www.ietf.org/rfc/rfc2731.txt
NORMAS
REV. ESP. DOC. CIENT., 29, 2, ABRIL-JUNIO, 287-296, 2006. ISSN 0210-0614 291
[TGN] Getty Thesaurus of Geographic Names.
http://www.getty.edu/research/tools/vocabulary/tgn/index.html
[W3CDTF] Date and Time Formats. W3C Note.
http://www.w3.org/TR/NOTE-datetime
[XML] Extensible Markup Language
http://www.w3.org/TR/REC-xml
3. Definiciones
DCMI — Dublin Core Metadata Initiative. La agencia encargada del mantenimiento del Dublin Core
Recurso de información — «Algo que tiene identidad» (la misma definición que en la RFC 2396) Ciclo de vida de un recurso de información— Una secuencia de hechos que marcan el desarrollo y el uso de un recurso de información. Algunos ejemplos de hechos en un ciclo de vida son: La concepción de una invención, la creación de un borrador, la revisión de un artículo, la publicación de un libro, el proceso de adquisición en una biblioteca, la trascripción a disco magnético, la migración a un sistema de almacenamiento óptico, una traducción al inglés, y la versión de un nuevo trabajo (p. ej. una película).
4. El conjunto de elementos
En la descripción de elementos que se hace a continuación, cada uno de ellos tiene una etiqueta descriptiva, cuya finalidad es dar a conocer una semántica común que facilite la comprensión del elemento, y un nombre constituido por una única palabra, entendible por máquina, cuyo objetivo es simplificar la descripción sintáctica de los elementos para los esquemas de codificación.
Aunque en algunos entornos, como HTML, no hay diferenciación entre mayúsculas y minúsculas, se recomienda siempre como práctica más recomendable atenerse a las convenciones de uso de mayúscula/minúscula en los nombres de los elementos que
se proponen a continuación, para evitar problemas en el caso de que los metadatos se extraigan o se conviertan posteriormente a un entorno donde sí se diferencian mayúsculas y minúsculas como puede ser XML (Lenguaje de Marcado Extensible [XML].
Cada elemento es opcional y repetible. Los elementos de metadatos pueden aparecer en cualquier orden. La ordenación de múltiples ocurrencias del mismo elemento (por ej. Creator) puede tener algún significado intencionado por el que proporciona
el recurso, pero no se puede garantizar que el orden se mantenga en todos los sistemas.
Para promover la interoperabilidad global, algunas de las descripciones de los elementos sugieren un vocabulario controlado para la asignación de valores. Asimismo se asume que se desarrollarán otros vocabularios controlados para conseguir la interoperabilidad dentro de algunos dominios informativos específicos o locales.
5. Elementos
Nombre del elemento: Title
Etiqueta: Título
Definición: Un nombre dado al recurso.
Comentario: Normalmente, el título será el nombre por el que se conoce formalmente el recurso.
Nombre del elemento: Creator
Etiqueta: Creador
Definición: Una entidad que es responsable principal de la elaboración del contenido del recurso.
Comentario: Ejemplos de creador de un recurso pueden ser, una persona, una organización o un servicio. Normalmente este campo debería utilizarse para indicar la entidad.
Nombre del elemento: Subject
Etiqueta: Materias y palabras clave
Definición: Un tema del contenido del recurso
Comentario: Normalmente, la materia se expresará con palabras clave, descriptores o códigos de clasificación que representen el tema del recurso. La práctica más recomendable es seleccionar estos valores de un vocabulario controlado o de un esquema formal de clasificación.
Nombre del elemento: Description
Etiqueta: Descripción
Definición: Una descripción del contenido del recurso
Comentario: Aunque no se limitan a estos, algunos ejemplos de descripción son un resumen, un índice de contenido, una explicación en texto libre o una referencia a una representación gráfica del contenido.
Nombre del elemento: Publisher
Etiqueta: Editor
Definición: Una entidad responsable de que el recurso esté disponible.
Comentario: Ejemplos de editor son: una persona, una organización o un servicio.
Normalmente el nombre de un editor debería utilizarse para indicar la entidad.
Nombre del elemento: Contributor
Etiqueta: Colaborador
Definición: Una entidad responsable de realizar contribuciones al contenido de
un recurso.
Comentario: Ejemplos de colaborador pueden ser: una persona, una organización o un servicio. Normalmente el nombre de un colaborador debe utilizarse para indicar la entidad.
Nombre del elemento: Date
Etiqueta: Fecha
Definición: Una fecha de un hecho relativo al ciclo de vida del recurso.
Comentario: Normalmente la fecha se asociará con la creación o la disponibilidad del recurso. La práctica más recomendable para codificar el valor de la fecha se define en el perfil ISO 8601 [W3CDTF] que incluye fechas de la forma AAAAMM-
DD.
Nombre del elemento: Type
Etiqueta: Tipo de recurso
Definición: La naturaleza o género del contenido del recurso.
Comentario: El tipo se refiere a términos que describen categorías generales,
funciones, géneros o niveles de agregación para el contenido. La práctica más recomendable
en este sentido es seleccionar un valor de un vocabulario controlado (por ejemplo, del DCMI Type Vocabulary [DCT1]). Para describir la manifestación física o digital del recurso debe emplearse el elemento Format.
Nombre del elemento: Formato
Etiqueta: Formato
Definición: La manifestación física o digital del recurso.
Comentario: Normalmente el formato se referirá a los tipos de medios o dimensiones de un recurso. El formato puede usarse para identificar el software, hardware u otros equipamientos necesarios para visualizar el recurso u operar con él. Ejemplos de dimensiones pueden ser el tamaño o la duración. La práctica más recomendable en este caso es seleccionar el valor de un vocabulario controlado (por ejemplo,la lista de Internet Media Types [MIME]).
Nombre del elemento: Identifier
Etiqueta: Identificador del recurso
Definición: Una referencia inequívoca al recurso dentro de un contexto determinado.
Comentario: La práctica más recomendable es identificar el recurso por medio de una cadena de caracteres o por un número conforme a un sistema formal de identificación. Algunos sistemas identificación formal de recursos son, entre otros, el
Uniform Resource Identifier (URI) que incluye el Localizador Uniforme de RecurNORMAS 294 REV. ESP. DOC. CIENT., 29, 2, ABRIL-JUNIO, 287-296, 2006. ISSN 0210-0614 sos (URL), el Digital Object Identifier (DOI) y el International Standard Book Number (ISBN).
Nombre del elemento: Source
Etiqueta: Fuente
Definición: Una referencia a un recurso del cual deriva el que se está describiendo.
Comentario: El recurso que se está describiendo puede derivar, en todo o en parte, de un recurso fuente. La práctica más recomendable en este caso es identificar el recurso referenciado por medio de una cadena de caracteres o número conforme
con un sistema de identificación formal.
Nombre del elemento: Language
Etiqueta: Idioma
Definición: Un idioma del contenido intelectual del recurso.
Comentario: La práctica más recomendable es usar la RFC 3066 [RFC3066] que, en conjunción con la norma ISO 639 [ISO639], define etiquetas de dos y tres letras para identificar el idioma principal, con subetiquetas opcionales. Algunos ejemplos son: «en» o «eng» para Inglés, «akk» para el acadio, y «en-GB» para el inglés utilizado en el Reino Unido.
Nombre del elemento: Relation
Etiqueta: Relación
Definición: Una referencia a un recurso relacionado.
Comentario: La práctica más recomendable es identificar los recursos referenciados por medio de una cadena de caracteres o número conforme a un sistema de identificación formal.
Nombre del elemento: Coverage
Etiqueta: Cobertura
Definición: La extensión o el alcance del contenido del recurso.
Comentario: Normalmente la cobertura incluirá la localización espacial (un nombre de un lugar o unas coordenadas geográficas), el periodo temporal (una expresión que identifica un período, fecha o rango de fecha) o la jurisdicción (por ejemplo una denominación de una entidad administrativa). La práctica más recomendable es seleccionar un valor de un vocabulario controlado (por ejemplo, del
Thesaurus of Geographical Names [TGN]) y usar, cuando sea oportuno, nombres de periodos de tiempo o de lugares, mejor que identificadores numéricos, como conjuntosde coordenadas o rangos de fecha.
Nombre del elemento: Rights
Etiqueta: Derechos
Definición: Información sobre los derechos contenidos en y sobre el recurso.
Comentario: Normalmente los derechos contendrán una declaración de gestión de derechos para el recurso, o una referencia a un servicio que proporcione dicha información. La información sobre los derechos normalmente abarca los derechos de Propiedad Intelectual (PI), derechos de autor y otros derechos relacionados con la propiedad. Si no consta el elemento de derechos no se deben hacer asunciones sobre ningún derecho contenido en el recurso o entorno a él.
Anexo A:
Información complementaria
(Este anexo no forma parte del Estándar Nacional Americano sobre el Conjunto de Elementos de Metadatos Dublin Core, ANSI/NISO Z39.85-2001. Se incluye solamente a nivel informativo). Se puede encontrar información complementaria sobre el Conjunto de Metadatos Dublin Core en el URL http://dublincore.org e información en español sobre esta norma en el mirror de la iniciativa en este idioma en el URL http://es.dublincore.org Ambos sitios web tienen información (en inglés y español, respectivamente) sobre los talleres, informes, documentos de los grupos de trabajo, proyectos y nuevos desarrollos relacionados con la Iniciativa de Metadatos Dublin Core (DCMI).
Anexo B:
Agencia responsable del mantenimiento de este estándar
(Este anexo no forma parte de Estándar Nacional Americano Conjunto de Elementos de Metadatos Dublin Core, ANSI/NISO Z39.85-2001. Se incluye solamente a nivel informativo). La Iniciativa de Metadatos Dublin Core es la responsable del desarrollo, Normalización y promoción del conjunto de elementos de metadatos Dublin Core. Se puede encontrar información sobre la DCMI en el URL http://dublincore.org.
N O R M A S
REVISTA ESPAÑOLA DE DOCUMENTACIÓN CIENTÍFICA
29, 2, ABRIL-JUNIO, 287-296, 2006
ISSN 0210-0614
miércoles, 30 de diciembre de 2009
Estándar para Metadatos Dublin Core
Dublin Core es un modelo de metadatos elaborado y auspiciado por la DCMI (Dublin Core Metadata Initiative), una organización dedicada a fomentar la adopción extensa de los estándares interoperables de los metadatos y a promover el desarrollo de los vocabularios especializados de metadatos para describir recursos para permitir sistemas más inteligentes del descubrimiento del recurso.
Las implementaciones de Dublin Core usan generalmente XML y se basan en el Resource Description Framework. Dublin Core se define por ISO en su norma ISO 15836 del año 2003, y la norma NISO Z39.85-2007.
El nombre viene por Dublín (Ohio, Estados Unidos), ciudad que en 1995 albergó la primera reunión a nivel mundial de muchos de los especialistas en metadatos y Web de la época.
Descripción general: Dublin Core es un sistema de 15 definiciones semánticas descriptivas que pretenden transmitir un significado semántico a las mismas.
Estas definiciones:
Son opcionales
Se pueden repetir
Pueden aparecer en cualquier orden
Este sistema de definiciones fue diseñado específicamente para proporcionar un vocabulario de características "base", capaces de proporcionar la información descriptiva básica sobre cualquier recurso, sin que importe el formato de origen, el área de especialización o el origen cultural.
Clasificación y elementos: En general, podemos clasificar estos elementos en tres grupos que indican la clase o el ámbito de la información que se guarda en ellos:
Elementos relacionados principalmente con el contenido del recurso.
Elementos relacionados principalmente con el recurso cuando es visto como una propiedad intelectual.
Elementos relacionados principalmente con la instanciación del recurso.
Dentro de cada clasificación encontramos los siguientes elementos:
Contenido:
- Título: el nombre dado a un recurso, habitualmente por el autor.
Etiqueta: DC.Title
- Claves: los tópicos del recurso. Típicamente, Subject expresará las claves o frases que describen el título o el contenido del recurso. Se fomentará el uso de vocabularios controlados y de sistemas de clasificación formales.
Etiqueta: DC.Subject
- Descripción: una descripción textual del recurso. Puede ser un resumen en el caso de un documento o una descripción del contenido en el caso de un documento visual.
Etiqueta: DC.Description
- Fuente: secuencia de caracteres usados para identificar unívocamente un trabajo a partir del cual proviene el recurso actual.
Etiqueta: DC.Source
- Lengua: lengua/s del contenido intelectual del recurso.
Etiqueta: DC.Language
- Relación: es un identificador de un segundo recurso y su relación con el recurso actual. Este elemento permite enlazar los recursos relacionados y las descripciones de los recursos.
Etiqueta: DC.Relation
- Cobertura: es la característica de cobertura espacial y/o temporal del contenido intelectual del recurso. La cobertura espacial se refiere a una región física, utilizando por ejemplo coordenadas. La cobertura temporal se refiere al contenido del recurso, no a cuándo fue creado (que ya lo encontramos en el elemento Date).
Etiqueta: DC.Coverage
Propiedad Intelectual:
- Autor o Creador: la persona o organización responsable de la creación del contenido intelectual del recurso. Por ejemplo, los autores en el caso de documentos escritos; artistas, fotógrafos e ilustradores en el caso de recursos visuales.
Etiqueta: DC.Creator
- Editor: la entidad responsable de hacer que el recurso se encuentre disponible en la red en su formato actual.
Etiqueta: DC.Publisher
- Otros Colaboradores: una persona u organización que haya tenido una contribución intelectual significativa, pero que esta sea secundaria en comparación con las de las personas u organizaciones especificadas en el elemento Creator. (por ejemplo: editor, ilustrador y traductor).
Etiqueta: DC.Contributor
- Derechos: son una referencia (por ejemplo, una URL) para una nota sobre derechos de autor, para un servicio de gestión de derechos o para un servicio que dará información sobre términos y condiciones de acceso a un recurso.
Etiqueta: DC.Rights
Instanciación:
- Fecha: una fecha en la cual el recurso se puso a disposición del usuario en su forma actual. Esta fecha no se tiene que confundir con la que pertenece al elemento Coverage, que estaría asociada con el recurso en la medida que el contenido intelectual está de alguna manera relacionado con aquella fecha.
Etiqueta: DC.Date
- Tipo del Recurso: la categoría del recurso. Por ejemplo, página personal, romance, poema, diccionario, etc.
Etiqueta: DC.Type
- Formato: es el formato de datos de un recurso, usado para identificar el software y, posiblemente, el hardware que se necesitaría para mostrar el recurso.
Etiqueta: DC.Format
- Identificador del Recurso: secuencia de caracteres utilizados para identificar unívocamente un recurso. Ejemplos para recursos en línea pueden ser URLs i URNs. Para otros recursos pueden ser usados otros formatos de identificadores, como por ejemplo ISBN ("International Standard Book Number").
Etiqueta: DC.Identifier
Usos: Cualquier persona puede utilizar los metadatos de Dublin Core para describir los recursos de un sistema de información. Las páginas Web son uno de los tipos más comunes de recursos que utilizan las descripciones de Dublin Core.
Los metadatos de Dublin Core están siendo utilizados como la base para los sistemas descriptivos para varios grupos de interés como por ejemplo:
Organizaciones educativas
Bibliotecas
Instituciones del gobierno.
Sector científico de la investigación.
Autores de páginas Web.
Negocios que requieren lugares más investigables.
Corporaciones con sistemas de gerencia extensos en conocimiento
Ventajas [editar]La simplicidad
La flexibilidad
La independencia sintáctica
La interoperabilidad semántica
Alto nivel de normalización formal
Crecimiento y evolución del estándar a través de una institución formal consorciada: la DCMI.
Consenso internacional
Modularidad de Metadatos en la Web
Arquitectura de Metadatos para la Web
Las implementaciones de Dublin Core usan generalmente XML y se basan en el Resource Description Framework. Dublin Core se define por ISO en su norma ISO 15836 del año 2003, y la norma NISO Z39.85-2007.
El nombre viene por Dublín (Ohio, Estados Unidos), ciudad que en 1995 albergó la primera reunión a nivel mundial de muchos de los especialistas en metadatos y Web de la época.
Descripción general: Dublin Core es un sistema de 15 definiciones semánticas descriptivas que pretenden transmitir un significado semántico a las mismas.
Estas definiciones:
Son opcionales
Se pueden repetir
Pueden aparecer en cualquier orden
Este sistema de definiciones fue diseñado específicamente para proporcionar un vocabulario de características "base", capaces de proporcionar la información descriptiva básica sobre cualquier recurso, sin que importe el formato de origen, el área de especialización o el origen cultural.
Clasificación y elementos: En general, podemos clasificar estos elementos en tres grupos que indican la clase o el ámbito de la información que se guarda en ellos:
Elementos relacionados principalmente con el contenido del recurso.
Elementos relacionados principalmente con el recurso cuando es visto como una propiedad intelectual.
Elementos relacionados principalmente con la instanciación del recurso.
Dentro de cada clasificación encontramos los siguientes elementos:
Contenido:
- Título: el nombre dado a un recurso, habitualmente por el autor.
Etiqueta: DC.Title
- Claves: los tópicos del recurso. Típicamente, Subject expresará las claves o frases que describen el título o el contenido del recurso. Se fomentará el uso de vocabularios controlados y de sistemas de clasificación formales.
Etiqueta: DC.Subject
- Descripción: una descripción textual del recurso. Puede ser un resumen en el caso de un documento o una descripción del contenido en el caso de un documento visual.
Etiqueta: DC.Description
- Fuente: secuencia de caracteres usados para identificar unívocamente un trabajo a partir del cual proviene el recurso actual.
Etiqueta: DC.Source
- Lengua: lengua/s del contenido intelectual del recurso.
Etiqueta: DC.Language
- Relación: es un identificador de un segundo recurso y su relación con el recurso actual. Este elemento permite enlazar los recursos relacionados y las descripciones de los recursos.
Etiqueta: DC.Relation
- Cobertura: es la característica de cobertura espacial y/o temporal del contenido intelectual del recurso. La cobertura espacial se refiere a una región física, utilizando por ejemplo coordenadas. La cobertura temporal se refiere al contenido del recurso, no a cuándo fue creado (que ya lo encontramos en el elemento Date).
Etiqueta: DC.Coverage
Propiedad Intelectual:
- Autor o Creador: la persona o organización responsable de la creación del contenido intelectual del recurso. Por ejemplo, los autores en el caso de documentos escritos; artistas, fotógrafos e ilustradores en el caso de recursos visuales.
Etiqueta: DC.Creator
- Editor: la entidad responsable de hacer que el recurso se encuentre disponible en la red en su formato actual.
Etiqueta: DC.Publisher
- Otros Colaboradores: una persona u organización que haya tenido una contribución intelectual significativa, pero que esta sea secundaria en comparación con las de las personas u organizaciones especificadas en el elemento Creator. (por ejemplo: editor, ilustrador y traductor).
Etiqueta: DC.Contributor
- Derechos: son una referencia (por ejemplo, una URL) para una nota sobre derechos de autor, para un servicio de gestión de derechos o para un servicio que dará información sobre términos y condiciones de acceso a un recurso.
Etiqueta: DC.Rights
Instanciación:
- Fecha: una fecha en la cual el recurso se puso a disposición del usuario en su forma actual. Esta fecha no se tiene que confundir con la que pertenece al elemento Coverage, que estaría asociada con el recurso en la medida que el contenido intelectual está de alguna manera relacionado con aquella fecha.
Etiqueta: DC.Date
- Tipo del Recurso: la categoría del recurso. Por ejemplo, página personal, romance, poema, diccionario, etc.
Etiqueta: DC.Type
- Formato: es el formato de datos de un recurso, usado para identificar el software y, posiblemente, el hardware que se necesitaría para mostrar el recurso.
Etiqueta: DC.Format
- Identificador del Recurso: secuencia de caracteres utilizados para identificar unívocamente un recurso. Ejemplos para recursos en línea pueden ser URLs i URNs. Para otros recursos pueden ser usados otros formatos de identificadores, como por ejemplo ISBN ("International Standard Book Number").
Etiqueta: DC.Identifier
Usos: Cualquier persona puede utilizar los metadatos de Dublin Core para describir los recursos de un sistema de información. Las páginas Web son uno de los tipos más comunes de recursos que utilizan las descripciones de Dublin Core.
Los metadatos de Dublin Core están siendo utilizados como la base para los sistemas descriptivos para varios grupos de interés como por ejemplo:
Organizaciones educativas
Bibliotecas
Instituciones del gobierno.
Sector científico de la investigación.
Autores de páginas Web.
Negocios que requieren lugares más investigables.
Corporaciones con sistemas de gerencia extensos en conocimiento
Ventajas [editar]La simplicidad
La flexibilidad
La independencia sintáctica
La interoperabilidad semántica
Alto nivel de normalización formal
Crecimiento y evolución del estándar a través de una institución formal consorciada: la DCMI.
Consenso internacional
Modularidad de Metadatos en la Web
Arquitectura de Metadatos para la Web
Mas sobre metadatos...
Metadatos (del griego μετα, meta, «después de»[1] y latín datum, «lo que se da», «dato»[2] ), literalmente «sobre datos», son datos que describen otros datos. En general, un grupo de metadatos se refiere a un grupo de datos, llamado recurso. El concepto de metadatos es análogo al uso de índices para localizar objetos en vez de datos. Por ejemplo, en una biblioteca se usan fichas que especifican autores, títulos, casas editoriales y lugares para buscar libros. Así, los metadatos ayudan a ubicar datos.[3]
Para varios campos de la informática, como la recuperación de información o la web semántica, los metadatos en etiquetas son un enfoque importante para construir un puente sobre el intervalo semántico.
Definiciones: El término «metadatos» no tiene una definición única. Según la definición más difundida de metadatos es que son «datos sobre datos». También hay muchas declaraciones como «informaciones sobre datos»,[4] «datos sobre informaciones»[5] e «informaciones sobre informaciones».[6]
Otra clase de definiciones trata de precisar el término como «descripciones estructuradas y opcionales que están disponibles de forma pública para ayudar a localizar objetos»[7] o «datos estructurados y codificadas que describen características de instancias conteniendo informaciones para ayudar a identificar, descubrir, valorar y administrar las instancias descritas».[8] Esta clase surgió de la crítica de que las declaraciones más simples son tan difusas y generales que dificultarán la tarea de acordarse de estándares, pero estas definiciones no son muy comunes.
En el campo biológico los metadatos se han convertido en una herramienta fundamental para el descubrimiento de datos e información, en este contexto se pueden definir los metadatos como «una descripción estandarizada de las características de un conjunto de datos» con esto se incluye la descripción del contexto en el cual los datos fueron coleccionados y además se refiere al uso de estándares para describirlos.
Distinción entre datos y metadatos: La mayoría de las veces no es posible diferenciar entre datos y metadatos. Por ejemplo, un poema es un grupo de datos, pero también puede ser un grupo de metadatos si está adjuntado a una canción que lo usa como texto.
Muchas veces, los datos son tanto "datos" como "metadatos". Por ejemplo, el título de un texto es parte del texto como a la vez es un dato referente al texto (dato como metadato).
Metadatos sobre metadatos: Debido a que los metadatos son datos en sí mismos, es posible crear metadatos sobre metadatos. Aunque, a primera vista, parece absurdo, los metadatos sobre metadatos pueden ser muy útiles. Por ejemplo, fusionando dos imágenes y sus metadatos distintos puede ser muy importante deducir cuál es el origen de cada grupo de metadatos, registrando ello en metadatos sobre los metadatos.
Objetivos: El uso de los metadatos mencionado más frecuentemente es la refinación de consultas a buscadores. Usando informaciones adicionales los resultados son más precisos, y el usuario se ahorra filtraciones manuales complementarias.
El intervalo semántico plantea el problema de que el usuario y el ordenador no se entiendan porque este último no comprenda el significado de los datos. Es posible que los metadatos posibiliten la comunicación declarando cómo están relacionados los datos. Por eso la representación del conocimiento usa metadatos para categorizar informaciones. La misma idea facilita la inteligencia artificial al deducir conclusiones automáticamente.
Los metadatos facilitan el flujo de trabajo convirtiendo datos automáticamente de un formato a otro. Para eso es necesario que los metadatos describan contenido y estructura de los datos.[9]
Algunos metadatos hacen posible una compresión de datos más eficaz. Por ejemplo, si en un vídeo el software sabe distinguir el primer plano del fondo puede usar algoritmos de compresión diferentes y así mejorar la cuota de compresión.[10]
Otra idea de aplicación es la presentación variable de datos. Si hay metadatos señalando los detalles más importantes, un programa puede seleccionar la forma de presentación más adecuada. Por ejemplo, si un teléfono móvil sabe dónde está localizada una persona en una imagen, tiene la posibilidad de reducirlo a las dimensiones de su pantalla. Del mismo modo un navegador puede decidir presentar un diagrama a su usuario ciego en forma táctil o leída.[11]
Clasificación : Los metadatos se clasifican usando tres criterios;
Contenido. Subdividir metadatos por su contenido es lo más común. Se puede separar los metadatos que describen el recurso mismo de los que describen el contenido del recurso. Es posible subdividir estos dos grupos más veces, por ejemplo para separar los metadatos que describen el sentido del contenido de los que describen la estructura del contenido o los que describen el recurso mismo de los que describen el ciclo vital del recurso.
Variabilidad. Según la variabilidad se puede distinguir metadatos mutables e inmutables. Los inmutables no cambian, no importa qué parte del recurso se vea, por ejemplo el nombre de un fichero. Los mutables difieren de parte a parte, por ejemplo el contenido de un vídeo.[12]
Función. Los datos pueden ser parte de una de las tres capas de funciones: subsimbólicos, simbólicos o lógicos. Los datos subsimbólicos no contienen información sobre su significado. Los simbólicos describen datos subsimbólicos, es decir añaden sentido. Los datos lógicos describen cómo los datos simbólicos pueden ser usados para deducir conclusiones lógicas, es decir añaden comprensión.[13]
Ciclo de vida [editar]El ciclo de vida de los metadatos comprende las fases creación, manipulación y destrucción. El análisis minucioso de cada una de las etapas saca a la luz asuntos significativos.
Creación: Se pueden crear metadatos manualmente, semiautomáticamente o automáticamente. El proceso manual puede ser muy laborioso, dependiente del formato usado y del volumen deseado, hasta un grado en el que los seres humanos no puedan superarlo. Por eso, el desarrollo de utillaje semiautomático o automático es más que deseable.
En la producción automática el software adquiere las informaciones que necesita sin ayuda externa. Aunque el desarrollo de algoritmos tan avanzados está siendo objeto de investigación actualmente, no es probable que la computadora vaya a ser capaz de extraer todos los metadatos automáticamente. En vez de ello, se considera la producción semiautomática más realista; aquí un servidor humano sostiene algoritmos autónomos con la aclaración de inseguridades o la proposición de informaciones que el software no puede extraer sin ayuda.
Hay muchos expertos que se encargan del diseño de herramientas para la creación de metadatos pero que ignoran cuestionar este proceso. Según los que no evitan el asunto, la generación no debe comenzar después de la terminación de un recurso si no que debe hacerse durante la fabricación: hay que archivar los metadatos tan pronto como se originan, con los conocimientos especiales del productor, para evitar una laboriosa reconstrucción posterior. Por eso, se tiene que integrar la producción de metadatos en el procedimiento de fabricación del recurso.[12]
Manipulación: Si los datos cambian, los metadatos tienen que cambiar también. Aquí se hace la pregunta quien va a adaptar los metadatos. Hay modificaciones que pueden ser manejadas sencilla y automáticamente, pero hay otras donde la intervención de un servidor humano es indispensable.
La metaproducción, el reciclaje de partes de recursos para crear otros recursos, demanda atención particular. La fusión de los metadatos afiliados no es trivial, especialmente si se trata de información con relevancia jurídica, como por ejemplo la gestión de derechos digitales...
Destrucción: Además hay que investigar la destrucción de metadatos. En algunos casos es conveniente eliminar los metadatos junto con sus recursos, en otros es razonable conservar los metadatos, por ejemplo para supervisar cambios en un documento de texto.
Almacenamiento: Hay dos posibilidades para almacenar metadatos; depositarlos internamente, en el mismo documento que los datos, o depositarlos externamente, en su mismo recurso. Inicialmente, los metadatos se almacenaban internamente para facilitar la administración.
Hoy, por lo general, se considera mejor opción la localización externa porque hace posible la concentración de metadatos para optimizar operaciones de busca. Por el contrario, existe el problema de cómo se liga un recurso con sus metadatos. La mayoría de los estándares usa URIs, la técnica de localizar documentos en la World Wide Web, pero este método propone otras preguntas, por ejemplo qué hacer con documentos que no tienen URI.
Codificación: Los primeros y más simples formatos de los metadatos usaron texto no cifrado o la codificación binaria para almacenar metadatos en ficheros.
Hoy, es común codificar metadatos usando XML. Así, son legibles tanto por seres humanos como por computadoras. Además este lenguaje tiene muchas características a su favor, por ejemplo es muy simple integrarlo en la World Wide Web. Pero también hay inconvenientes: los datos necesitan más espacio de memoria que en formato binario y no está claro cómo convertir la estructura de árbol en una corriente de datos.
Por eso, muchos estándares incluyen utilidades para convertir XML en codificación binaria y viceversa, de forma que se únen las ventajas de los dos.
Vocabularios controlados y ontologías: Para garantizar la uniformidad y la compatibilidad de los metadatos, muchos sugieren el uso de un vocabulario controlado fijando los términos de un campo. Por ejemplo, en caso de sinónimos o interlenguaje hay que acordarse qué palabras se usan para evitar que el buscador localice «español» pero no «española».
Una ontología además define las relaciones de los términos del vocabulario para que la computadora puede evaluarlas automáticamente. Así es posible presentar una página web sobre «Vincent van Gogh» aunque el usuario tecleó «pintores neerlandeses»; usando una ontología adecuada el buscador comprende que van Gogh fue un pintor neerlandés.
Un concepto muy similar a las ontologías son las folksonomías. Las ontologías son definidas por expertos del campo que ordenan los términos, pero las folksonomías son definidas por los mismos usuarios.
Crítica: Algunos expertos critican fuertemente el uso de metadatos. Sus argumentos más sustanciosos son:
Los metadatos son costosos y necesitan demasiado tiempo. Las empresas no van a producir metadatos porque no hay demanda y los usuarios privados no van a invertir tanto tiempo.
Los metadatos son demasiado complicados. La gente no acepta los estándares porque no los comprende y no quiere aprenderlos.
Los metadatos dependen del punto de vista y del contexto. No hay dos personas que añadan los mismos metadatos. Además, los mismos datos pueden ser interpretados de manera totalmente diferente, dependiendo del contexto.
Los metadatos son ilimitados. Es posible adherir más y más metadatos útiles y no hay fin.
Los metadatos son superfluos. Ya hay buscadores potentes para textos, y en el futuro la técnica query by example («búsqueda basada en un ejemplo») va a mejorarse, tanto para localizar imágenes como para música y vídeo.
Algunos estándares de metadatos están disponibles pero no se aplican: los críticos lo consideran una prueba de las carencias del concepto de metadatos. Hay que notar que este efecto también puede ser causado por insuficiente compatibilidad de los formatos o por la enorme diversidad que amedrenta a las empresas. Fuera de eso hay fomatos de metadatos muy populares.[7]
Formatos y estándares: Hay dos grupos que impulsan el desarrollo de formatos de metadatos: la técnica multimedia y la web semántica. El destino de la técnica multimedia es describir un singular recurso de multimedia, el de la web semántica la descripción de recursos de cada tipo y además el encadenamiento de los conocimientos. Los formatos más populares y grandes son:
ID3 hace posible la notación de metadatos muy sencillos, tales como título e intérprete, en ficheros de audio MP3. El formato es muy popular y demuestra que los metadatos pueden ser útiles.
MPEG-7
MPEG-21
TV-Anytime
Dublin Core
LOM
Marco de descripción de recursos (RDF)
RDF Schema
OWL
NewsML
SportsML
Fuentes:
1. Real Academia Española. Diccionario de la lengua española. Entrada «meta». 22.ª edición, 2001
2. Real Academia Española. Diccionario de la lengua española. Entrada «dato». 22.ª edición, 2001
3. Tim Bray. RDF and Metadata. 9 junio 1998, visitado 29 mayo 2006
4. Tom Sheldon. Linktionary. Entrada «Metadata». 2001, visitado 29 mayo 2006
5. A. Steinacker, A. Ghavam, R. Steinmetz. Metadata Standards for Web-Based Resources. IEEE MultiMedia, enero-marzo 2001
6. W3C, Ralph Swick. Metadata Activity Statement. 2002, visto 29 mayo 2006
7. a b D. C. A. Bultermann. Is It Time for a Moratorium on Metadata? IEEE Multimedia, 11(4):10-17, IEEE Computer Society Press, Los Alamitos, Ca, USA, octubre-diciembre 2004
8. W. R. Durrell. Data Administration. A Practical Guide to Data Administration. McGraw-Hill, 1985
9. C. Wroe, C. Goble, M. Greenwood, P. Lord, S. Miles, J. Papay, T. Payne, L. Moreau. Automating Experiments Using Semantic Data on a Bioinformatics Grid. IEEE Intelligent Systems, 19(1):48-55, enero/febrero 2004
10. H. Kosch, L. Böszörményi, M. Döller, M. Libsie, P. Schojer, A. Kofler. The Life Cycle of Multimedia Metadata. IEEE MultiMedia, 12(1), IEEE Computer Society Press, Los Alamitos, Ca, USA, enero 2005
11. M. Horstmann, M. Lorenz, A. Watkowski, et al. Automated interpretation and accessible presentation of technical diagrams for blind people. The New Review of Hypermedia and Multimedia, 10(29:141-163, Taylor & Francis Inc., Pa, USA, 2004
12. a b J. R. Smith, P. Schirling. Metadata Standards Roundup. IEEE MultiMedia, 13(2):84-88, IEEE Computer Society Press, Los Alamitos, Ca, USA, avril 2006
13. G. Stamou, J. v. Ossenbruggen, J. Pan, G. Schreiber. Multimedia Annotations on the Semantic Web. IEEE MultiMedia, 13(1):86-90, IEEE Computer Society Press, Los Alamitos, Ca, USA, enero-marzo 2006
Obtenido de "http://es.wikipedia.org/wiki/Metadato"
Para varios campos de la informática, como la recuperación de información o la web semántica, los metadatos en etiquetas son un enfoque importante para construir un puente sobre el intervalo semántico.
Definiciones: El término «metadatos» no tiene una definición única. Según la definición más difundida de metadatos es que son «datos sobre datos». También hay muchas declaraciones como «informaciones sobre datos»,[4] «datos sobre informaciones»[5] e «informaciones sobre informaciones».[6]
Otra clase de definiciones trata de precisar el término como «descripciones estructuradas y opcionales que están disponibles de forma pública para ayudar a localizar objetos»[7] o «datos estructurados y codificadas que describen características de instancias conteniendo informaciones para ayudar a identificar, descubrir, valorar y administrar las instancias descritas».[8] Esta clase surgió de la crítica de que las declaraciones más simples son tan difusas y generales que dificultarán la tarea de acordarse de estándares, pero estas definiciones no son muy comunes.
En el campo biológico los metadatos se han convertido en una herramienta fundamental para el descubrimiento de datos e información, en este contexto se pueden definir los metadatos como «una descripción estandarizada de las características de un conjunto de datos» con esto se incluye la descripción del contexto en el cual los datos fueron coleccionados y además se refiere al uso de estándares para describirlos.
Distinción entre datos y metadatos: La mayoría de las veces no es posible diferenciar entre datos y metadatos. Por ejemplo, un poema es un grupo de datos, pero también puede ser un grupo de metadatos si está adjuntado a una canción que lo usa como texto.
Muchas veces, los datos son tanto "datos" como "metadatos". Por ejemplo, el título de un texto es parte del texto como a la vez es un dato referente al texto (dato como metadato).
Metadatos sobre metadatos: Debido a que los metadatos son datos en sí mismos, es posible crear metadatos sobre metadatos. Aunque, a primera vista, parece absurdo, los metadatos sobre metadatos pueden ser muy útiles. Por ejemplo, fusionando dos imágenes y sus metadatos distintos puede ser muy importante deducir cuál es el origen de cada grupo de metadatos, registrando ello en metadatos sobre los metadatos.
Objetivos: El uso de los metadatos mencionado más frecuentemente es la refinación de consultas a buscadores. Usando informaciones adicionales los resultados son más precisos, y el usuario se ahorra filtraciones manuales complementarias.
El intervalo semántico plantea el problema de que el usuario y el ordenador no se entiendan porque este último no comprenda el significado de los datos. Es posible que los metadatos posibiliten la comunicación declarando cómo están relacionados los datos. Por eso la representación del conocimiento usa metadatos para categorizar informaciones. La misma idea facilita la inteligencia artificial al deducir conclusiones automáticamente.
Los metadatos facilitan el flujo de trabajo convirtiendo datos automáticamente de un formato a otro. Para eso es necesario que los metadatos describan contenido y estructura de los datos.[9]
Algunos metadatos hacen posible una compresión de datos más eficaz. Por ejemplo, si en un vídeo el software sabe distinguir el primer plano del fondo puede usar algoritmos de compresión diferentes y así mejorar la cuota de compresión.[10]
Otra idea de aplicación es la presentación variable de datos. Si hay metadatos señalando los detalles más importantes, un programa puede seleccionar la forma de presentación más adecuada. Por ejemplo, si un teléfono móvil sabe dónde está localizada una persona en una imagen, tiene la posibilidad de reducirlo a las dimensiones de su pantalla. Del mismo modo un navegador puede decidir presentar un diagrama a su usuario ciego en forma táctil o leída.[11]
Clasificación : Los metadatos se clasifican usando tres criterios;
Contenido. Subdividir metadatos por su contenido es lo más común. Se puede separar los metadatos que describen el recurso mismo de los que describen el contenido del recurso. Es posible subdividir estos dos grupos más veces, por ejemplo para separar los metadatos que describen el sentido del contenido de los que describen la estructura del contenido o los que describen el recurso mismo de los que describen el ciclo vital del recurso.
Variabilidad. Según la variabilidad se puede distinguir metadatos mutables e inmutables. Los inmutables no cambian, no importa qué parte del recurso se vea, por ejemplo el nombre de un fichero. Los mutables difieren de parte a parte, por ejemplo el contenido de un vídeo.[12]
Función. Los datos pueden ser parte de una de las tres capas de funciones: subsimbólicos, simbólicos o lógicos. Los datos subsimbólicos no contienen información sobre su significado. Los simbólicos describen datos subsimbólicos, es decir añaden sentido. Los datos lógicos describen cómo los datos simbólicos pueden ser usados para deducir conclusiones lógicas, es decir añaden comprensión.[13]
Ciclo de vida [editar]El ciclo de vida de los metadatos comprende las fases creación, manipulación y destrucción. El análisis minucioso de cada una de las etapas saca a la luz asuntos significativos.
Creación: Se pueden crear metadatos manualmente, semiautomáticamente o automáticamente. El proceso manual puede ser muy laborioso, dependiente del formato usado y del volumen deseado, hasta un grado en el que los seres humanos no puedan superarlo. Por eso, el desarrollo de utillaje semiautomático o automático es más que deseable.
En la producción automática el software adquiere las informaciones que necesita sin ayuda externa. Aunque el desarrollo de algoritmos tan avanzados está siendo objeto de investigación actualmente, no es probable que la computadora vaya a ser capaz de extraer todos los metadatos automáticamente. En vez de ello, se considera la producción semiautomática más realista; aquí un servidor humano sostiene algoritmos autónomos con la aclaración de inseguridades o la proposición de informaciones que el software no puede extraer sin ayuda.
Hay muchos expertos que se encargan del diseño de herramientas para la creación de metadatos pero que ignoran cuestionar este proceso. Según los que no evitan el asunto, la generación no debe comenzar después de la terminación de un recurso si no que debe hacerse durante la fabricación: hay que archivar los metadatos tan pronto como se originan, con los conocimientos especiales del productor, para evitar una laboriosa reconstrucción posterior. Por eso, se tiene que integrar la producción de metadatos en el procedimiento de fabricación del recurso.[12]
Manipulación: Si los datos cambian, los metadatos tienen que cambiar también. Aquí se hace la pregunta quien va a adaptar los metadatos. Hay modificaciones que pueden ser manejadas sencilla y automáticamente, pero hay otras donde la intervención de un servidor humano es indispensable.
La metaproducción, el reciclaje de partes de recursos para crear otros recursos, demanda atención particular. La fusión de los metadatos afiliados no es trivial, especialmente si se trata de información con relevancia jurídica, como por ejemplo la gestión de derechos digitales...
Destrucción: Además hay que investigar la destrucción de metadatos. En algunos casos es conveniente eliminar los metadatos junto con sus recursos, en otros es razonable conservar los metadatos, por ejemplo para supervisar cambios en un documento de texto.
Almacenamiento: Hay dos posibilidades para almacenar metadatos; depositarlos internamente, en el mismo documento que los datos, o depositarlos externamente, en su mismo recurso. Inicialmente, los metadatos se almacenaban internamente para facilitar la administración.
Hoy, por lo general, se considera mejor opción la localización externa porque hace posible la concentración de metadatos para optimizar operaciones de busca. Por el contrario, existe el problema de cómo se liga un recurso con sus metadatos. La mayoría de los estándares usa URIs, la técnica de localizar documentos en la World Wide Web, pero este método propone otras preguntas, por ejemplo qué hacer con documentos que no tienen URI.
Codificación: Los primeros y más simples formatos de los metadatos usaron texto no cifrado o la codificación binaria para almacenar metadatos en ficheros.
Hoy, es común codificar metadatos usando XML. Así, son legibles tanto por seres humanos como por computadoras. Además este lenguaje tiene muchas características a su favor, por ejemplo es muy simple integrarlo en la World Wide Web. Pero también hay inconvenientes: los datos necesitan más espacio de memoria que en formato binario y no está claro cómo convertir la estructura de árbol en una corriente de datos.
Por eso, muchos estándares incluyen utilidades para convertir XML en codificación binaria y viceversa, de forma que se únen las ventajas de los dos.
Vocabularios controlados y ontologías: Para garantizar la uniformidad y la compatibilidad de los metadatos, muchos sugieren el uso de un vocabulario controlado fijando los términos de un campo. Por ejemplo, en caso de sinónimos o interlenguaje hay que acordarse qué palabras se usan para evitar que el buscador localice «español» pero no «española».
Una ontología además define las relaciones de los términos del vocabulario para que la computadora puede evaluarlas automáticamente. Así es posible presentar una página web sobre «Vincent van Gogh» aunque el usuario tecleó «pintores neerlandeses»; usando una ontología adecuada el buscador comprende que van Gogh fue un pintor neerlandés.
Un concepto muy similar a las ontologías son las folksonomías. Las ontologías son definidas por expertos del campo que ordenan los términos, pero las folksonomías son definidas por los mismos usuarios.
Crítica: Algunos expertos critican fuertemente el uso de metadatos. Sus argumentos más sustanciosos son:
Los metadatos son costosos y necesitan demasiado tiempo. Las empresas no van a producir metadatos porque no hay demanda y los usuarios privados no van a invertir tanto tiempo.
Los metadatos son demasiado complicados. La gente no acepta los estándares porque no los comprende y no quiere aprenderlos.
Los metadatos dependen del punto de vista y del contexto. No hay dos personas que añadan los mismos metadatos. Además, los mismos datos pueden ser interpretados de manera totalmente diferente, dependiendo del contexto.
Los metadatos son ilimitados. Es posible adherir más y más metadatos útiles y no hay fin.
Los metadatos son superfluos. Ya hay buscadores potentes para textos, y en el futuro la técnica query by example («búsqueda basada en un ejemplo») va a mejorarse, tanto para localizar imágenes como para música y vídeo.
Algunos estándares de metadatos están disponibles pero no se aplican: los críticos lo consideran una prueba de las carencias del concepto de metadatos. Hay que notar que este efecto también puede ser causado por insuficiente compatibilidad de los formatos o por la enorme diversidad que amedrenta a las empresas. Fuera de eso hay fomatos de metadatos muy populares.[7]
Formatos y estándares: Hay dos grupos que impulsan el desarrollo de formatos de metadatos: la técnica multimedia y la web semántica. El destino de la técnica multimedia es describir un singular recurso de multimedia, el de la web semántica la descripción de recursos de cada tipo y además el encadenamiento de los conocimientos. Los formatos más populares y grandes son:
ID3 hace posible la notación de metadatos muy sencillos, tales como título e intérprete, en ficheros de audio MP3. El formato es muy popular y demuestra que los metadatos pueden ser útiles.
MPEG-7
MPEG-21
TV-Anytime
Dublin Core
LOM
Marco de descripción de recursos (RDF)
RDF Schema
OWL
NewsML
SportsML
Fuentes:
1. Real Academia Española. Diccionario de la lengua española. Entrada «meta». 22.ª edición, 2001
2. Real Academia Española. Diccionario de la lengua española. Entrada «dato». 22.ª edición, 2001
3. Tim Bray. RDF and Metadata. 9 junio 1998, visitado 29 mayo 2006
4. Tom Sheldon. Linktionary. Entrada «Metadata». 2001, visitado 29 mayo 2006
5. A. Steinacker, A. Ghavam, R. Steinmetz. Metadata Standards for Web-Based Resources. IEEE MultiMedia, enero-marzo 2001
6. W3C, Ralph Swick. Metadata Activity Statement. 2002, visto 29 mayo 2006
7. a b D. C. A. Bultermann. Is It Time for a Moratorium on Metadata? IEEE Multimedia, 11(4):10-17, IEEE Computer Society Press, Los Alamitos, Ca, USA, octubre-diciembre 2004
8. W. R. Durrell. Data Administration. A Practical Guide to Data Administration. McGraw-Hill, 1985
9. C. Wroe, C. Goble, M. Greenwood, P. Lord, S. Miles, J. Papay, T. Payne, L. Moreau. Automating Experiments Using Semantic Data on a Bioinformatics Grid. IEEE Intelligent Systems, 19(1):48-55, enero/febrero 2004
10. H. Kosch, L. Böszörményi, M. Döller, M. Libsie, P. Schojer, A. Kofler. The Life Cycle of Multimedia Metadata. IEEE MultiMedia, 12(1), IEEE Computer Society Press, Los Alamitos, Ca, USA, enero 2005
11. M. Horstmann, M. Lorenz, A. Watkowski, et al. Automated interpretation and accessible presentation of technical diagrams for blind people. The New Review of Hypermedia and Multimedia, 10(29:141-163, Taylor & Francis Inc., Pa, USA, 2004
12. a b J. R. Smith, P. Schirling. Metadata Standards Roundup. IEEE MultiMedia, 13(2):84-88, IEEE Computer Society Press, Los Alamitos, Ca, USA, avril 2006
13. G. Stamou, J. v. Ossenbruggen, J. Pan, G. Schreiber. Multimedia Annotations on the Semantic Web. IEEE MultiMedia, 13(1):86-90, IEEE Computer Society Press, Los Alamitos, Ca, USA, enero-marzo 2006
Obtenido de "http://es.wikipedia.org/wiki/Metadato"
pero ¿qué es la Documentación ?
Según Wikipedia:
En sentido restringido, la documentación como ciencia documental se podría definir (a grandes rasgos) como la ciencia del procesamiento de la información. Integradora y globalizadora, se trata de una ciencia enriquecedora y generalista, de ámbito multidisciplinar o interdisciplinar. La ciencias de la documentación engloban, según la mayoría de los autores: la biblioteconomía, la archivística, la documentación y la museología.
A falta de un consenso, hay diversos autores, como Juan Ros García o José López Yepes, que la consideran una ciencia (documental), a la vez que una disciplina, no sólo una técnica. También pueden considerarse, en sentido general, las ciencias de la documentación y la documentación como sinónimos, si el contexto no perturba la intención del emisor, es decir, si no se distorsiona el mensaje del interlocutor porque no se dé ambigüedad semántica.
Historia: Cada ciencia documental tiene una larga historia, pero la más antigua es sin duda la archivística. Según el país, se trata de unos estudios universitarios con titulación superior (existente en dos ciclos antes de la Convergencia Europea, por ejemplo en Japón), con un nombre u otro, pero que también se imparte en centros de enseñanza privados desde hace años. En América Latina, la carrera profesional suele denominarse "Bibliotecología y Ciencias de la Información".
Algoritmo científico: Tiene que ver con la gestión del conocimiento, que es como utilizar cualquier clase de información y hacerla productiva o que dé el máximo beneficio, como si se tratara de otro bien económico. Asimismo, tiene que ver con arquitectura de la información o como se construyen los modelos para los soportes: Internet o encuestas, datos numéricos, fotografías, mapas, diarios, artículos de revistas, etc., es decir, un número ilimitado de soportes. También tiene el modelo la connotación de un método científico, mediante un algoritmo, que valida los resultados de búsqueda mediante la utilización de base de datos relacionales (tablas de datos).
Biblioteconomía: En biblioteconomía es la recuperación y presentación clasificada, ordenada y valorada de documentos impresos y de vídeo y audio sobre un tema preciso, que puede ser un artículo o un sistema o un producto o un descriptor. En una obra científica es la bibliografía de un informe final, tanto la que ha sido utilizada como la sugerida de ampliación. En cinematografía, es la recopilación de fuentes escritas o audiovisuales sobre una película (documentación de un tema).
En la obra científica o de no ficción formará parte de los créditos de la calidad del trabajo o bibliografía utilizada, y es parte del trabajo desarrollado, donde deberán figurar listas de fuentes; también son técnicas de documentación los glosarios, los índices temáticos y de autores citados, tablas auxiliares, etc.
Como funciones de un bibliotecario-documentalista profesional, como autor o como colaborador, el especialista en documentación conoce todas las variantes descritas y utiliza programas de cómputo específicamente desarrollados por programadores y que él mismo puede adaptar a cada tarea, como por ejemplo construir de forma instantánea un índice de materias por el método de palabras utilizadas y sus frecuencias o hacer un análisis de contenido o construir algún tipo de indicador de medida de la información o investigar sobre algoritmos de búsqueda o sobre motores de búsqueda en el ámbito de la informática.
El modelo de un sistema de información será con un modelo sistémico aplicado a un sistema complejo. Incluirá la captación de fuentes y su adecuación al problema a documentar; esto será la primordial tarea. El propósito es hacer máxima la cantidad de información captada y mínima la básica utilizable.
En el proceso de un trabajo sobre cualquier tema se comienza con documentarse sobre lo que se va a trabajar, y la forma más simple es consultar enciclopedias temáticas o bases de datos en Internet, como Wikipedia.org, monografías.com, geocities.com, Dialnet, Diccionario Crítico de Ciencias Sociales, enciclopedia.com, etc. De una forma progresiva se encuentran fuentes nuevas y mucha información precisa.
En sentido restringido, la documentación como ciencia documental se podría definir (a grandes rasgos) como la ciencia del procesamiento de la información. Integradora y globalizadora, se trata de una ciencia enriquecedora y generalista, de ámbito multidisciplinar o interdisciplinar. La ciencias de la documentación engloban, según la mayoría de los autores: la biblioteconomía, la archivística, la documentación y la museología.
A falta de un consenso, hay diversos autores, como Juan Ros García o José López Yepes, que la consideran una ciencia (documental), a la vez que una disciplina, no sólo una técnica. También pueden considerarse, en sentido general, las ciencias de la documentación y la documentación como sinónimos, si el contexto no perturba la intención del emisor, es decir, si no se distorsiona el mensaje del interlocutor porque no se dé ambigüedad semántica.
Historia: Cada ciencia documental tiene una larga historia, pero la más antigua es sin duda la archivística. Según el país, se trata de unos estudios universitarios con titulación superior (existente en dos ciclos antes de la Convergencia Europea, por ejemplo en Japón), con un nombre u otro, pero que también se imparte en centros de enseñanza privados desde hace años. En América Latina, la carrera profesional suele denominarse "Bibliotecología y Ciencias de la Información".
Algoritmo científico: Tiene que ver con la gestión del conocimiento, que es como utilizar cualquier clase de información y hacerla productiva o que dé el máximo beneficio, como si se tratara de otro bien económico. Asimismo, tiene que ver con arquitectura de la información o como se construyen los modelos para los soportes: Internet o encuestas, datos numéricos, fotografías, mapas, diarios, artículos de revistas, etc., es decir, un número ilimitado de soportes. También tiene el modelo la connotación de un método científico, mediante un algoritmo, que valida los resultados de búsqueda mediante la utilización de base de datos relacionales (tablas de datos).
Biblioteconomía: En biblioteconomía es la recuperación y presentación clasificada, ordenada y valorada de documentos impresos y de vídeo y audio sobre un tema preciso, que puede ser un artículo o un sistema o un producto o un descriptor. En una obra científica es la bibliografía de un informe final, tanto la que ha sido utilizada como la sugerida de ampliación. En cinematografía, es la recopilación de fuentes escritas o audiovisuales sobre una película (documentación de un tema).
En la obra científica o de no ficción formará parte de los créditos de la calidad del trabajo o bibliografía utilizada, y es parte del trabajo desarrollado, donde deberán figurar listas de fuentes; también son técnicas de documentación los glosarios, los índices temáticos y de autores citados, tablas auxiliares, etc.
Como funciones de un bibliotecario-documentalista profesional, como autor o como colaborador, el especialista en documentación conoce todas las variantes descritas y utiliza programas de cómputo específicamente desarrollados por programadores y que él mismo puede adaptar a cada tarea, como por ejemplo construir de forma instantánea un índice de materias por el método de palabras utilizadas y sus frecuencias o hacer un análisis de contenido o construir algún tipo de indicador de medida de la información o investigar sobre algoritmos de búsqueda o sobre motores de búsqueda en el ámbito de la informática.
El modelo de un sistema de información será con un modelo sistémico aplicado a un sistema complejo. Incluirá la captación de fuentes y su adecuación al problema a documentar; esto será la primordial tarea. El propósito es hacer máxima la cantidad de información captada y mínima la básica utilizable.
En el proceso de un trabajo sobre cualquier tema se comienza con documentarse sobre lo que se va a trabajar, y la forma más simple es consultar enciclopedias temáticas o bases de datos en Internet, como Wikipedia.org, monografías.com, geocities.com, Dialnet, Diccionario Crítico de Ciencias Sociales, enciclopedia.com, etc. De una forma progresiva se encuentran fuentes nuevas y mucha información precisa.
¿Qué son los Metadatos?
Los metadatos son datos de datos. Son como las fichas bibliográficas de los libros pero en este caso de cualquier documento. Los metadatos consisten en información que caracterizan datos. En esencia intentan responder a las preguntas: ¿Quién? , ¿Qué? , ¿Cuando?, ¿Donde? , ¿ Porque?, y ¿Cómo?, sobre cada una de las facetas relativas a los datos que se documentan. El fin último de los metadatos, es ayudar a publicitar y dar soporte a los datos que las organizaciones han producido. Los metadatos almacenados en BD estándares producen catálogos.
Son muy importantes en la documentación de sistemas (en su comcepto amplio), es decir, sirven para documentar lo que sea pues desde la visión sistémica todo es un sistema y por ende objeto de documentación.
Por esta razón queremos exponer nuestra visión de la documentación desde este concepto para hacer nuestro aporte ya que es importantísimo para los objetivos actuales de esta materia.
Son muy importantes en la documentación de sistemas (en su comcepto amplio), es decir, sirven para documentar lo que sea pues desde la visión sistémica todo es un sistema y por ende objeto de documentación.
Por esta razón queremos exponer nuestra visión de la documentación desde este concepto para hacer nuestro aporte ya que es importantísimo para los objetivos actuales de esta materia.
Suscribirse a:
Comentarios (Atom)