|
Preguntas más
frecuentes sobre metadatos:
Esta lista de preguntas más frecuentes y sus respuestas
no
representan ninguna posición oficial del Clearinghouse del Uruguay
ni de las fuentes mencionadas.
Contenidos
 Motivación
- ¿Qué son los metadatos?
- Los metadatos consisten en información que caracteriza datos. Los
metadatos son utilizados para suministrar información sobre datos
producidos. En esencia, los metadatos intentan responder a las
preguntas quién, que, cuando, donde, porqué y cómo, sobre cada una de
las facetas relativas a los datos que se documentan.
- Los sistemas en línea para manejar metadatos necesitan manipular
objetos predecibles en forma y contenido. El carácter de
predecible se logra mediante el ajuste de los mismos a
estándares. En el Clearinghouse del Uruguay se ha decidido utilizar el
estándar americano Content
Standards for Digital Geospatial Metadata. En donde se requiera,
se le denominará brevemente como el estándar FGDC por más que
ese organismo maneje también otros estándares (como el de
transferencia de datos espaciales, también conocido como STDS)
- ¿Porqué deberían crearse metadatos?
- El fin último de los metadatos, es ayudar a publicitar y dar
soporte a los datos que ud. o su organización han producido.
El producto básico que se maneja en el Clearinghouse del Uruguay
son metadatos, elaborados por sí o por los proveedores, de forma de
conformar en conjunto un catálogo en línea de datos espaciales
(digitales o no). El Clearinghouse permitirá a la gente comprender las
virtudes y limitaciones de los datos disponibles por la vía de
describirlos en una forma que enfatiza aspectos que les son
comunes.
- ¿Quién debería crear los metadatos?
- Es un trabajo o bien para administradores de sistemas que manejan
con soltura conceptos científicos, o bien para científicos que manejan
con soltura conceptos de informática. La tarea de crear metadatos
correctos es como la de catalogar libros, excepto que el creador
necesita conocer bastante más sobre los datos mismos para poder
documentarlos apropiadamente. No debe asumirse que todos los técnicos
en geografía, geología, etc. deben estar capacitados para escribir
metadatos. Ellos se quejarán (con razón) que la tarea es muy
engorrosa y no verán los beneficios en forma inmediata. De todas
formas hay que asegurarse que hay una buena comunicación entre quien
efectivamente escribe los metadatos, y el productor de los datos; el
primero tiene que hacerle muchas preguntas al segundo.
- ¿Porqué es eso tan difícil?!
- Desafortunadamente, nada se consigue sin esfuerzo. Si bien la
ganancia no necesariamente es proporcional al esfuerzo, cero esfuerzo
probablemente da cero ganancia. En el caso de los catálogos de
biblioteca, ellos no son producidos por los autores de libros o
revistas, y ello es por una buena razón. Para tener consistencia en la
documentación de productos muy diversos se necesita seguir una
metodología en forma estricta. El caso de los metadatos geográficos es
similar, pero requiere un detalle mayor sobre los datos mismos.
¿Qué se puede hacer con la gente que se queja de que esto es muy
difícil? La solución en muchos casos es rediseñar el flujo del
trabajo, más que hacer esfuerzos mayores en herramientas o
entrenamiento. La gente muchas veces asume que el productor de datos
debería generar sus propios metadatos. Por supuesto que ellos deberán
proporcionar documentación informal, sin estructura, pero ellos no
tienen porqué necesariamente pasar y sufrir los rigores de lograr
metadatos completamente estructurados. Para aquellos científicos o
especialistas en SIG que a lo sumo producen uno o dos juegos de datos
al año simplemente no vale la pena que inviertan tiempo en aprender el
estándar vigente. En su lugar, ellos deberían ser invitados a llenar
un formulario menos complicado (o template) que será traducido
al formato apropiado por el administrador de los datos. Si treinta o
cuarenta científicos están produciendo datos y le envían el formulario
al administrador, entonces seguramente valdrá la pena para el analizar
y dominar el estándar. Si la comunicación es buena, esta estrategia
probablemente supere a cualquier combinación de herramientas de
software y entrenamiento de personal..
El estándar de metadatos
- ¿Porqué es el estándar de metadatos tan
complejo?
- Tanto el estándar del FGDC como el ISO (en preparación) han sido
diseñados para describir todos los posibles datos geoespaciales.
- Hay 334 diferentes elementos en el estándar del FGDC, 119
de los cuales existen únicamente para contener otros elementos. Estos
elementos compuestos son importantes porque describen las
relaciones entre otros elementos. Por ejemplo, una referencia
bibliográfica se describe con un elemento denominado
Citation_Information el que contiene a la vez un título
(Title) y una fecha de publicación
(Publication_Date). Es necesario saber qué fecha de
publicación corresponde a un título en particular; la relación
jerárquica descrita por Citation_Information se encarga de
eso
- ¿Qué es eso de Metadata-Lite?
- La mejor discusión sobre este tópico se debe a Hugh Phillips, y
pertenece a la lista de correo electrónico NSDI-L (para suscribirse
envíe e-mail a majordomo@www.fgdc.gov).
- El texto dice:
- En los últimos meses han habido muchos mensajes en la lista
respecto a la existencia de un "núcleo" de metadatos (metadata
core). Muchos de los mensajes reflejan frustración debido a la
complejidad del estándar y sugieren la opción de trabajar con un
núcleo simplificado del estándar completo. En el otro extremo, otros
colegas reconocen que el estándar completo ya es el núcleo en el
sentido que representan la información necesaria para evaluar, obtener
y usar el juego de datos.
- Una sugerencia ha sido la definición de un "conjunto mínimo de
búsqueda", donde se incluirían los campos que los servidores del
Clearinghouse deberían indizar, y que podrían ser buscados
individualmente. Han habido propuestas para este conjunto, como por
ejemplo el "Dublin core" o el "Denver core". Los campos que deberían
incluirse en el "Denver core" incluyen:
Theme_Keywords
Place_Keywords
Bounding_Coordinates
Abstract
Purpose
Time_Period_of_Content
Currentness_Reference
Geospatial_Data_Presentation_Form
Originator
Title
Language
Resource_Description
- El idioma de los metadatos es un elemento que de momento no
aparece en el estándar, pero es un problema a considerar en Europa o
incluso en el Mercosur. De todas formas, no hay porqué descartar el
uso del Denver core como un conjunto mínimo de búsqueda; todos
los campos que aparecen en el Denver core ya son obligatorios
en el estándar, por lo que siempre deberán aparecer. Sin
embargo, estoy enfáticamente en contra de la idea de definir un núcleo
que sea un subconjunto del FGDC. Si eso se hiciera, los elementos de
ese núcleo pasarían a ser el estándar. Nadie crearía metadatos
completos (en el sentido del estándar) y por lo tanto será imposible
discernir ciertos aspectos de los datos tales como su calidad, sus
atributos, o cómo obtenerlos. Yo siento simpatía por aquellos que
sienten que el estándar FGDC es oneroso y que ellos no tienen tiempo
para documentar in extenso sus propios datos. Como se ha
dicho: no existe policía de metadatos.
- El hecho concreto es que se ha dicho que es "demasiado difícil" o
que "no hay suficiente tiempo". Ser "muy difícil" es una situación
asociada a la falta de familiaridad con el estándar y frustración por
lo complejo de su estructura. Esto puede remediarse si existieran más
metadatos como ejemplos y FAQs disponibles para ampliar el
conocimiento y difundir el tema, por la vía de tratar realmente de
seguir al estándar lo mejor que uno pueda, usando herramientas de
metadatos que aíslen al usuario de las complejidades internas de la
estructura. Siempre el primer juego de datos documentados será el
peor. El otro aspecto vinculado a "demasiado difícil" puede deberse a
que al documentar un juego de datos a fondo requiere muchas veces una
(dolorosa) mirada al detalle de los datos, y trae a la luz lo
poco que realmente se conoce de la historia de los mismos, o de su
procesamiento.
- Otra queja frecuente es "falta de tiempo" para documentar. En
estas situaciones es donde deben aparecer los gerentes que aprecian el
valor de los datos de SIG, y pueden por tanto poner prioridades para
proteger su inversión por la vía de disponer tiempo para documentarla.
Dedicar uno o dos días documentando un juego de datos que pudo haber
requerido meses o años en ser desarrollado, a un costo de miles de
dólares difícilmente pueda parecer un tiempo excesivo.
- Estas preocupaciones por "esfuerzo" y "tiempo" pueden tener
legitimidad, especialmente para agencias que producen cientos de
juegos de datos que podrían ser documentados, pero para los cuales esa
tarea los sacaría de proyectos en curso. En ese momento, es quizá
mejor tener un montón de metadatos muy simplificados que tener unos
pocos metadatos generosamente documentados. Por lo tanto...¿qué
recomendaciones dar a quienes quieren usar un núcleo como vía para
reducir el esfuerzo de documentación?
- Primero que nada, no invente su propio estándar. Ya existe uno.
Incluso cambios sutiles al estándar como colapsar elementos completos
le costará en el largo plazo, porque ud. no será capaz de usar
herramientas estándares y sus metadatos no serán intercambiables ni
consultables desde el exterior
- No confunda la presentación (apariencia) de los metadatos
con los metadatos mismos
- Evalúe la granularidad de los datos. ¿Es posible que ud.
documente muchos de sus juegos de datos bajo un único paraguas?
Linda Hill and Mary Larsgaard han propuesto recientemente una forma
robusta para realizar esto en una modificación al estándar que
parece muy interesante.
- Priorice sus datos. Empiece documentando aquellos juegos de
datos que tienen uso actual o futuro, o que son parte esencial del
trabajo de otros, o que representan una fracción importante de los
esfuerzos de su organización ya sea en esfuerzos, tiempo o costo.
- Documente hasta un nivel que preserve el valor de los datos
dentro de su propia organización. Evalúe que pasaría con el valor de
sus datos si su administrador gerente de SIG de repente decide
cambiar su vida por un estilo primitivo en una isla tropical.
- Fin del texto de Hugh Phillips
- ¿Es posible crear nuevos elementos para incluir
en los metadatos?
- Seguro. Eso se denomina extensiones y deben ser utilizadas
con precaución. Primero que nada, ud. no debería agregar ningún
elemento que ud. piense que es una obvia omisión. Si ud piensa
que el estándar dejó de lado algo que todo el mundo necesitará,
probablemente encontrará un lugar para esa información en el estándar
existente. Lo que si puede ocurrir es que el nombre o la posición del
elemento del estándar puede ser diferente de la que ud. espera. Por
otra parte, extensiones específicas a la aplicación son comunes. Toda
disciplina científica tiene términos y calidades que son únicas o que
son compartidas sólo con otras pocas. Esto no puede ser incorporado en
la práctica directamente en el estándar, por ello aquí están los pasos
para crear extensiones :
- Las extensiones son elementos no incluídos en el estandar para
manejar información usada o requerida en una disciplina
particular.
Por ejemplo: en biología, la Taxonomía es un componente
de los metadatos, y es la raíz de una rama que describe
clasificaciones biológicas.
- Las extensiones no deben ser agregadas sólo para cambiar el
nombre de un elemento existente. Los nombres de los elementos son
esencialmente un problema que se puede resolver en la interfase
usuario del software que usa/manipula los metadatos.
Ejemplo: No agregue elementos a
Supplemental_Information; ese campo se ha definido como
conteniendo texto libre.
- Redefinir un elemento compuesto existente como un único
elemento escalar no constituye una extensión, y es un error.
Ejemplo: La Descripción contiene los elementos Abstract,
Purpose, y Supplemental_Information. Estos componentes no deben
ser reemplazados por texto libre.
- Los elementos existentes pueden ser incluídos como hijos
(children) de las extensiones, pero su inclusión no
deberán duplicar sus funciones dentro de los elementos del
estándar.
Ejemplo: Para indicar la información de contacto de
productores que no han sido designados como Point_of_Contact
(punto de contacto), crear un elemento adicional
Originator_Contact, formado por Contact_Information. Pero el
elemento Point_of_Contact es todavía requerido, aún si la persona
que se va a describir es uno de los productores.
- ¿Cómo se pueden crear metadatos?
- Primero ud. tiene que entender a la vez los datos que tratará de
describir y el estándar mismo. Luego ud. deberá decidir sobre cómo
codificará la información. Normalmente, ud. creará un único archivo
para cada metadatos, o sea, un archivo describe un juego de datos.
Luego ud. utilizará algún programa para ingresar información al
archivo, de forma que los metadatos cumplan con el estándar.
Específicamente:
- Recoja información sobre el juego de datos.
- Cree un archivo digital que contenga los metadatos, organizado
apropiadamente.
- Verifique la estructura sintáctica del archivo, y modifique la
organización de la información y repita luego hasta que la
estructura sintáctica sea correcta
- Verifique los contenidos de los metadatos, comprobando que la
información describe los datos completa y correctamente.
Una disgresión sobre conformidad e
interoperabilidad
- El estándar FGDC realmente estandariza los contenidos y no
define la organización de los metadatos en archivos de computadora.
Dado que el estándar es tan complejo, esto tiene el efecto práctico
que casi cualquier metadato puede declarar que verifica el estándar;
el archivo conteniendo metadatos sólo tiene que contener la
información apropiada, y esa información no tiene porqué ser
fácilmente interpretable o accesible por una persona o incluso una
computadora.
Esta noción en sentido amplio de conformidad no es realmente muy
útil. Desafortunadamente, es muy común. Es muy difícil discutir que un
archivo no contiene la información requerida por el estándar. Pero
para ser realmente útil, los metadatos claramente deben ser
comparables con otros metadatos, no sólo en forma visual, sino por
software que indice, busque y recupere los documentos desde la
internet o intranet. Para ser realmente valiosos, los metadatos deben
ser a la vez legibles por la máquina (parseable) e interoperable, o
sea que puedan trabajarse con software usado en el Clearinghouse.
 Parseable
- El término parse indica la acción de analizar la
información por la via de subdividirla y reconocer sus componentes.
Que los metadatos sean "parseables" requiere que la información
asociada a un elemento esté claramente separada de la de otros
elementos. Mas aún, los valores de los elementos están no sólo
separados uno de otro, sino que están claramente relacionados con
los nombres de los elementos correspondientes, y estos últimos
claramente relacionados entre sí como lo están en el estándar.
- En la práctica esto quiere decir que sus metadatos deben estar
organizados en una jerarquía, como lo están los elementos en el
estándar, y deberán usar los nombres estándar para los elementos
como la vía para identificar la información contenida en los valores
de tal elemento.
- Interoperable
- Para operar con software en el Clearinghouse, sus metadatos
deben ser legibles y procesables por ese software. Generalmente,
esto quiere decir que deben ser parseables y deben identificar los
elementos en la forma esperada por el software.
En USA, el grupo de trabajo del Clearinghouse del FGDC ha
decidido que los metadatos se intercambian utilizando
SGML (Standard Generalized Markup Language) ajustándose al
estándar Document Type Declaration (DTD) desarrollado por el USGS en
coordinación con el FGDC.
- ¿Qué herramientas hay disponibles para crear
metadatos?
- En principio, ud. podría crear metadatos en SGML usando
simplemente un editor de texto. Sin embargo, esto no es muy
recomendable porque es muy fácil cometer errores, como omitir, digitar
erróneamente o ubicar las tags que cierran los elementos compuestos.
Estos errores son difíciles de encontrar y de corregir. Otro enfoque
más productivo consiste en crear los metadatos usando una herramienta
que entienda el estándar
- Una de esas herramientas es Xtme
(cuyo nombre sale de Xt Metadata Editor). Este editor funciona en UNIX
con el X Window System, versión 11, release 5 o superior. Su salida
tiene el formato apropiado para ser ingresado a mp (ver más abajo)
Hugh Phillips ha preparado un excelente resumen de herramientas
para metadatos, incluyendo revisiones y links a las herramientas y su
documentación. Se la puede encontrar en <URL:http://badger.state.wi.us/agencies/wlib/sco/metatool/mtools.htm>
- ¿Qué herramientas están disponibles para
verificar o comprobar la estructura de los metadatos?
- El
programa mp está diseñado para analizar metadatos codificados como
texto indentado, comprobar la estructura sintáctica contra el
estándar, y reexpresar los metadatos en varios formatos útiles (HTML,
SGML, TEXT, y DIF).
- ¿Qué herramienta está disponible para verificar
la precisión de los metadatos?
- Ninguna herramienta puede hacer esto. Mas aún, ninguna herramienta
puede determinar si los metadatos incluyen elementos que el estándar
especifica como obligatorios si corresponde.
- Inevitablemente se requiere una revisión por un experto. Pero
usualmente la revisión por un experto es más simple si ya se sabe que
los metadatos tienen la estructura sintáctica correcta.
- ¿Puedo simplemente comprar software que esté de
acuerdo con el estándar?
- La respuesta es NO. Las herramientas no pueden autodeclararse como
de acuerdo al estándar. Si así lo fuera, serían incapaces de producir
metadatos que NO se ajusten al estándar, para lo cual tendría que
anticipar todos los posibles juegos de datos que se le planteen. Esto
es simplemente imposible. Lo que sí pueden ofrecer las herramientas es
asistencia en el ingreso de los metadatos, dado que los archivos que
se produzcan deberán ser inevitablemente verificados sintácticamente y
en su contenido en pasos separados.
- El estándar sólo hablan de metadatos, y sólo de ellos puede
decirse que lo cumplen o no.
- ¿Porqué es el Atributo un componente de Dominio
del Rango y Dominio Enumerado?
- Este elemento aparece con la intención de describir atributos que
explican el valor de otro atributo. Un ejemplo puede ayudar. El autor
de un juego de datos suministró un número real (algo como 0.1044327)
en un atributo, y otro atributo que estaba relacionado podía tener el
valor "X"o ninguno (vacío). La presencia del valor "X" en el segundo
atributo indicaba que el valor del primer atributo era extremadamente
sospechoso debido a las características de la muestra observada que
sólo eran notadas luego que la medida fue realizada. Por ejemplo si
hubiese algo como:
| Muestra |
Medida1 |
Calidad1 |
Medida2 |
| A1 |
0.880201 |
|
0.3 |
| B2 |
0.910905 |
x |
0.4 |
| C3 |
0.570118 |
x |
0.2 |
| C3 |
0.560518 |
|
0.1 |
- La variable Calidad 1 existe solamente para indicar que algunos
valores de Medida1 son cuestionables. Nótese que los valores de
Medida2 no están calificados de la misma manera; las variaciones en la
calidad de Medida2 probablemente están descritas en los metadatos.
- En resumen, la componente Attribute de Range_Domain y
Enumerated_Domain permiten a los metadatos describir datos en los
cuales algunos atributos califican el valor de otro atributo.
- Algunos expertos opinan que esto describe los datos con mucho más
detalle estructural de lo que la mayoría de la gente espera, y en el
ejemplo citado arriba había tandas variables (430) que
rápidamente pasamos de la Detailed_Description a una
Overview_Description. Si existiesen herramientas bonitas
(¿VisualData++?) que entendieran la relación entre atributos como
éste, la gente estaría mucho más interesada en producir los metadatos
en esta manera tan detallada. De todos modos, pienso que la idea
básica tiene sentido.
Formato del archivo de metadatos
- ¿Cuál es el formato de archivo para los
metadatos?
- El formato para intercambiar metadatos es SGML, de acuerdo con el
Documento de Declaración de Tipo del FGDC (Document
Type Declaration). Esto no es el tipo de cosas que uno le gustaría
hacer a mano.La manera más practica de generar ese tipo de archivo es
usar el programa mp,
que es un compilador de metadatos formales. Esta herramienta toma como
entrada un archivo ASCII en el cual los nombres de los elementos son
traducidos y se construye una estructura jerárquica usando una
indentación consistente. Información más completa sobre el estándar
norteamericano en uso para este formato puede encontrarse en <URL:http://geochange.er.usgs.gov/pub/tools/metadata/tools/doc/encoding.html>
- ¿Podría ud. explicar someramente sobre la
lógica detrás de recomendar SGML?
- Argumentos a favor de SGML:
- Es un estándar internacional, usado extensamente en otros campos
como la industria publicitaria
- Está soportada por muchísimo software, tanto libre como
comercial.
- Con él se puede verificar la estructura de los metadatos, tal
como lo hace mp.
- Otras herramientas (desafortunadamente muy nuevas) permiten
que los documentos en SGML ser reexpresados en formas arbitrarias
usando lenguajes de intérpretes,Document Style Semantics
ySpecification Language (DSSSL), los que son también un estándar
ISO.
- Puede en principio, manejar extensiones arbitrarias
- Argumentos en contra de SGML:
- La comunidad de productores de metadatos no tiene aún mucha
experiencia usándolo para resolver problemas.
- No estamos utilizando herramientas de SGML; lo único que hacemos
con SGML es crear nuestros índices para buscar con él.
- El aprender a usar SGML en forma efectiva agrega costos
significativos a la formación para manipular metadatos. Imagínise un
usuario de SIG, enfrascado para aprender ARC/INFO. El o ella quieren
producir datos bien documentados, y para eso comienzan por aprender
el estándar de metadatos, que tiene 335 elementos organizados en una
jerarquía compleja. Para usar SGML en forma efectiva, el tendría que
conocer los principios generales de SGML, así como algunos
procedimientos. El tendría que seleccionar, ubicar, instalar y
aprender a usar algún software de SGML. Para crear reportes a medida
debería aprender DSSSL (con un manual de 300 páginas) que está en
realidad escrito con un subconjunto de LISP llamado Scheme (con otro
manual de 50 páginas). Hasta que se comience a usar el SGML para
metadatos esta no será una solución satisfactoria.
- El actual DTD no admite todavía extensiones.
- Conclusión:
- El objetivo es utilizar SGML para manejar metadatos en el futuro,
pero el camino continuará con el desarrollo de mp y sus parientes
cercanos, asegurandos que esas herramientas soporten la migración a
SGML. Se necesita mucho más experiencia invertida en el desarrollo de
SGML, y esto no ha ocurrido aún. Para propósitos prácticos la solución
más completa en el momento es xtme->mp o
cns->xtme->mp. Estas herramientas ya manejan
extensiones arbitrarias, y mp puede crear salidas SGML si se requieren
para procesamiento posterior. Cuando sea posible, deberíamos alentar a
las agencias y oficinas a invertir en el desarrollo de herramientas
para manejar metadatos en SGML, pero esto no es meramente un problema
de "vaya y cómprelo" sino que es más bien un problema de "apréndalo a
usar", lo que es mucho más costoso.
- ¿Porqué debería usar indentaciones?
- No debería. Lo que ud tendría que hacer es comunicar con algún
método la estructura jerárquica de sus metadatos. Ud. tiene que
presentar esa jerarquía en una forma que la computadora pueda
comprender sin intervención del usuario. La manera (legible) más
simple de hacer eso es usando texto
indentado con los nombres de los elementos como tags. Ud. podría
usar SGML directamente, pero tendría que asegurarse de que cierra cada
elemento en forma apropiada. El estándar DTD no admite que falten esos
cierres. Y como mp puede generar SGML para ud siempre y cuando le
alimente con texto indentado...
- ¿Porqué no puedo usar los números de sección
del estándar?
- Ellos probablemente serán cambiados. Ellos son esencialmente
como números de página; ante cualquier revisión del estándar, tanto
los números de páginas como los de sección han de cambiar
- Ellos no son informativos. Los que leen los metadatos
normalmente estarán mucho menos informado de la estructura de los
estándares de metadatos que los productores, por lo que no
comprenderán en absoluto los números.
- Ellos expresan la jerarquías pero no la información. Para
elementos que están anidados y se repiten, los números muestran el
anidado pero no la repetición, por lo que no arrastran bien la
estructura.
- No es más simple usar números. Los nombres largos pueden ser
copiados a sus metadatos usando el sistema de intercambio dinámico
de datos de su sistema de ventana, por lo que ud. no tiene que
digitarlos. Aún mejor, puede comenzar trabajando con una plantilla
que tenga los nombres largos, o use un editor que los provea.
- Si he estado utilizando una plantilla
(template) que mp no puede leer...¿Qué puedo hacer con los
registros ya creados?
- Procéselos a través del programa cns.
Es un pre-parser que intentará adivinar la estructura jerárquica de
metadatos que no están indentados apropiadamente. El trabajo es algo
ingenioso, y no se puede esperar que cns comprenda cualquier
cosa que ud. haya hecho. Por eso, ud. tendrá que mirar atentamente la
salida, y agregar información que se transfiere al archivo de
leftovers junto con el input para mp que se produce. El
siguiente paso es utilizar mp.
- ¿Cómo maneja mp los elementos que son
"obligatorios si corresponde"?
- Los casos "obligatorios si corresponde" son manejados como mp como
si fuesen opcionales. No debe olvidarse que mp es una herramienta para
verificar la estructura sintáctica, no la precisión del contenido.
Inevitablemente tendrá que existir una persona que lea los metadatos
producidos para comprobar si lo que dice de los datos es correcto.
- ¿Se puede comenzar a ingresar los valores de un
elemento cualquiera en una línea, y continuar en las líneas
siguientes?
- Así es. Antes no se podía pero ahora este formato es admisible:
Title: Geometeorological data collected by the USGS Desert Winds
Project at Gold Spring, Great Basin Desert, northeastern
Arizona, 1979 - 1992
- ¿Puedo variar la indentación en el texto?
- Sí. Pero las variaciones en la indentación no serán preservadas en
los archivos de salida. No intente mantener ningún formato en los
archivos de entrada; el formato no sobrevivirá posteriores
procesamientos. La variación de indentación que está permitida luce
como esto:
Title:
Geometeorological data collected
by the USGS Desert Winds
Project at Gold Spring, Great Basin Desert, northeastern
Arizona, 1979 - 1992
Ejecutando mp, xtme, y cns
- ¡Socorro!
- Hay ayuda disponible. Por favor envíe un email a pschweitzer@usgs.gov
solicitando ser incluído en la lista de corredo de mp-users.
Generalmente se intenta así notificar a los usuarios de cambios en el
software, así como pedir asistencia a esos usuarios.
- ¿Porqué obtengo tantos mensajes?
- A veces un único error produce muchos mensajes. Si ud. especifica
demasiados ítems en algo, ud. obtendrá un mensaje de los elementos
padres así como de los hijos, con similares contenidos.
- ¿Qué son esos números de línea?
- Los números corresponden a las líneas en su archivo de ingreso.
Use un editor de texto que sea capaz de indicarle en que número de
línea se encuentra (o mejor aún, que pueda saltar a una línea
determinada) de forma que pueda entender el mensaje de error. Ud.
puede encontrar un editor de esos en <URL:http://geochange.er.usgs.gov/pub/tools/xed/>.
- ¿A qué corresponden los errores tipo
"(unknown) is not permitted in name"?
- Ciertamente ud. puso algo en el lugar incorrecto. Si ud. piensa
que si está en el lugar correcto, mire con atención;
pudo haber omitido un contenedor, como Citation_Information,
Time_Period_Information, o Contact_Information. Mp
requiere que la jerarquía completa esté incluida aunque la estructura
sea clara del contexto.
- ¿Puedo simplemente ignorar los
warnings?
- Siempre mírelos para intentar entender que es lo que significan. A
veces un warning es sólo un aviso de una organización no esperada.
Otras veces un warning puede indicar que sus metadatos no están siendo
interpretados en la manera que ud. piensa se debe.
- ¿A qué corresponden los warnings
"Element name 1 has child name 2,
expected (unknown); reclassifed as text"?
- El nombre oficial de un elemento aparece al principio de la línea
dentro del texto del elemento name 1. mp le está diciendo que
el considera que esto es texto plano en lugar de un nodo de la
jerarquía. Ignore el warning si realmente es texto plano. Si no lo es,
vea si se supone que eso vaya en algún otro lado.
- ¿Cómo maneja mp direcciones URL y códigos HTML
en general?
- A partir del 25 de Marzo de 1998 mp reconoce URLs en todos los
contextos y hace de ellos links en la salida con formato HTML. Ud. no
debería usar códigos HTML en los valores de los elementos porque no
hay razón para creer que en el futuro los metadatos serán procesados
por sistemas que comprendan HTML. Si ud. está obligado a agregar HTML
en el documento resultante, le recomiendo que que edite la salida HTML
que produce mp para este propósito.
- Note que mp ahora proporciona "preformateo", de forma que grupos
de líneas que comienzan con símbolos de mayor-que serán presentadas
con formato, precedidas con <pre> y seguidas de
</pre> en la salida HTML. Los símbolos de > serán
omitidos en la salida HTML. Por ejemplo, el siguiente elemento de
metadatos
Completeness_Report:
Data are missing for the following days
>19890604
>19910905
>19980325
- será representado como sigue en HTML:
<dt><em>Completeness_Report:</em>
<dd>
<pre>
19890604
19910905
19980325
</pre>
- ¿Porqué se queja cns cuando el nombre de un
elemento aparece al principio de una línea de texto?
- Esto es una limitación de cns. No es un procedimiento automático.
La lógica que usa cns para ver que es lo que hay en el archivo no
maneja bien alguna de estas situaciones. La razón porqué hace esto es
que intenta adivinar la estructura jerárquica en un texto que no ha
sido estructurado jerárquicamente. Necesariamente tiene que hacer
hipótesis sobre dónde encontrar los nombres estándares de elementos,
de forma de poder reconocerlos apropiadamente cuando están en los
lugares correctos. Cuando ud. usa cns, tiene que mirar cuidadosamente
a la vez en la entrada y la salida producida. Siempre revise el
archivo de los leftovers, porque puede mostrar realmente qué
tan severos son los problemas. Pero también debe estar prevenido que a
veces ocurren algunos problemas más sutiles; a veces un elemento mal
deletreado se incorpora al texto libre del elemento anterior.
- Can you forecast the fate of mp? A number of my
colleagues here have expressed concern about committing to tools that
"go away."
- En el fondo ese es un argumento en favor de SGML. A corto plazo no
tiene demasiado peso, porque no hemos desarrollado la capacidad de
hacer con SGML lo que mp hace ahora con texto indentado.
- Quisiera señalar también que en el tiempo que lleva de existencia,
mp ha tenido una historia de soporte mucho mejor que otras
herramientas diseñadas para producir metadatos (Ver mp-doc). Los que
le siguen son probablemente Corpsmet y MetaMaker. Otros paquetes han
sido abandonados por sus creadores, o no han sido mejorados.
- Por otra parte, el código fuente de mp está disponible en forma
libre. Ha sido compilado y ejecutado en muchos sistemas (más de 6
variedades de UNIX, MS-DOS, Win95+NT, y se sabe que funciona en muchos
otros sistemas UNIX). La tarea de actualizarlo puede ser demasiado
para un individuo que no esté familiarizado con C, pero la comunidad
de usuarios ya es tan grande que el software no depende de su creador
original.
- Y más que nada, hay que recordar que...
- La cosa más importante que debemos hacer para progresar es
crear documentación procesable y estructurada. La llave de todo el
esfuerzo es enfatizar qué es lo que es consistente sobre nuestra
gran variedad de juegos de datos, y explotar que la consistencia es
una manera de hacer más fácil descubrir y usar datos espaciales de
cualquier tipo. Siempre es posible combinar elementos de metadatos
para ajustarse a un esquema más general; la operación difícil
(porque requiere la atención de una persona experta y tiempo para
realizarlo) es ir en el otro sentido, buscando a través de un texto
no estructurado para desentrañar la información clave requerida.
Manejo y almacenamiento de metadatos
- ¿Cómo poner los metadatos en una base de datos
relacional?
- Es posible representar fácilmente recursión en un modelo
relacional. Por ejemplo:
CREATE TABLE attribute (
pk_attribute key_t PRIMARY KEY
fk_enumerated_domain key_t REFERENCES enumerated_domain
attribute_stuff ...
)
CREATE TABLE enumerated_domain (
pk_enumerated_domain key_t PRIMARY KEY
fk_attribute key_t REFERENCES attribute
enumerated_domain_stuff ...
)
- donde key_t es un tipo para guardar identificadores
únicos (e.g., Informix's SERIAL).
- La parte ingeniosa, por supuesto, es obtener la información de
vuelta. Es cierto, ud. no puede escribir una consulta en estándar
SQL-92 que atraviese el árbol implícito en el ejemplo precedente (i.e.
rebotará entre fk_enumerated_domain y fk_attribute hasta que
fk_attribute sea NULL). Sin embargo casi todos (¿o todos?) los
proveedores de DBMS soportan extensiones procedurales (por ejemplo,
looping) a SQL, lo que hace la consulta posible. Además, algunos
proveedores han extendido SQL para soportar directamente una consulta
estructurada en árbol (por ejemplo, la consulta CONNECT BY de Oracle)
directamente
- En última instancia, ud. tiene que considerar porqué está
guardando metadatos tipo FGDC en una base de datos relacional. Como
enseñanzas del proyecto Alexandria:
- Los atributos que son propensos a ser usados en una búsqueda
(e.g. Bounding_Coordinates) pueden ser manejados en forma
diferente de otros atributos que serán consultados solamente en
algún informe muy ocasional (e.g.
Metadata_Security_Handling_Description)
- Algunos atavismos del estándar (e.g. Dialup_Instructions)
simplemente no vale la pena mantenerlos. Muchas veces son estas
partes las que agregan la mayor complejidad.
- En otras palabras, a pesar de ser posible hacer todo con un
esquema relacional completamente normalizado, puede no ser
deseable.
Ejemplos de consultas SQL recursivas (references de Jim Frew)
- Celko, Joe (1995) Joe Celko's SQL for Smarties : Advanced SQL
programming. Morgan Kaufmann, San Francisco. [see chapter 26,
"Trees"]
- Date, C. J. (1995) An Introduction to Database Systems, 6th
ed. Addison-Wesley, Reading, MA. [see pp. 266..267]
- Informix Software, Inc. (1996) Informix Guide to SQL
(Tutorial, Version 7.2). Informix Press, Menlo Park, CA. [see pp.
5-27..5-29]
- Koch, George, and Kevin Loney (1997) ORACLE8: The Complete
Reference. Osborne/McGraw-Hill, Berkeley, CA. [see pp. 313..324]
Otras referencias
- Esquema y
scripts de la Alexandria Digital Library para metadatos
del FGDC y USMARC.
- Prototipo de instrucciones
de BLM para generar una implementación relacional del Estándar
de Metadatos en Informix.
Diseminación de los metadatos
- ¿Qué hay que hacer para convertirse en un nodo
del Clearinghouse?
- Tanto los aspectos institucionales como los técnicos pueden ser
abordados pidiendo una cita por correo electrónico o
directamente en el tercer piso del MTOP, en la Dirección Nacional de
Topografía.
Esta página es una traducción libre de información obtenida del USGS Geologic Information
En
particular, la página original en inglés es
<http://geochange.er.usgs.gov/pub/tools/metadata/tools/doc/faq.html>
El
original fue diseñado y es mantenido por Peter Schweitzer
La versión en
español es mantenida por clearingmaster
|
