Vazaar Project Blog » DC

Dublin Core

Fri, 07 Dec 2007 17:18:38 +0000

Este es el primero de una serie de artículos sobre Dublin Core (DC) y metadatos. Explicaré un poco la teoría e intentaré mostrar ejemplos prácticos de su uso en Vazaar. Para realizarlo me he ayudado de una traducción al español de DC que he encontrado en RedIris y diversa documentación que he ido encontrando en la web de Dublin Core. Antes de empezar definiendo que es Dublin Core hay que entender que son los metadatos. Por lo tanto,

¿Qué son los metadatos?

Los metadatos se pueden considerar como descripciones que hacemos sobre cualquier clase de recurso que nos ayude a encontrarlo, identificarlo, usarlo, manejarlo, evaluarlo y preservarlo.

¿Cómo se pueden usar los metadatos?

Puedes usarlos para:

descubrir servicios
identificar versiones
marcar la estructura del contenido
manejar documentos
certificar auntenticidad
situar geoespacialmente
control de derechos
indicar estatus
describir procesos

Bases de los metadatos

La unidad básica del metadato es una afirmación
Una afirmación consiste de una propiedad (elemento) y un valor
Todas estas afirmaciones describen los recursos

¿A quién le importa los metadatos?

El término “metadato” tiene sentido en contextos tales como:

El modelado de datos,
la catalogación de libros en bibliotecas
el descubrimeniento de nuevos recursos en internet

Metadatos y Dublin Core

Dublin Core 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 (extraído de la wikipedia).

Este vocabulario es el resultado de muchos años de búsqueda colaborativa con el objetivo de determinar un conjunto común de propiedades universales que describan cualquier tipo de recurso. El uso de sistemas de clasificación estandarizados hace posible que los metadatos de diferentes colecciones sean combinados y compartidos.

El vocabulario de Dublin Core está formado por elementos. Elementos con nombres descriptivos que pretenden transmitir un significado semántico a los mismos.

Podemos clasificar estos elementos en tres grupos que indican la clase o el ámbito de la información que se guarda en ellos:

1. Elementos relacionados principalmente con el contenido del recurso
2. Elementos relacionados principalmente con el recurso cuando es visto como una propiedad intelectual
3. Elementos relacionados principalmente con la instanciación del recurso

Los 15 elementos del vocabulario de Dublin Core:

	Elemento	Etiqueta	Descripción
1	Título	DC.Title	El nombre dado a un recurso, usualmente por el autor.
2	Autor	DC.Creator	La persona u organización responsable de la creación del contenido intelectual del recurso. Por ejemplo, los autores en el caso de documentos escritos, artistas, fotografos e ilustradoresen el caso de recursos visuales.
3	Claves	DC.Subject	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.
4	Descripción	DC.Description	Una descripción textual del recurso, tal como un resumen en el caso de un documento o una descripción del contenidoen el caso de un documento visual.
5	Editor	DC.Publisher	La entidad responsable de hacer que el recurso se encuentre disponible en la red en su formato actual. Por ejemplo la empresa editora, un departamento universitario u otro tipo de organización.
6	Colaboradores	DC.Contributor	Una persona u organizacion que haya tenido una contribución intelectual significativa en la creación del recurso pero cuyas contribuciones son secundarias en comparación a las de las personas u organizaciones especificadas en el elementeo Creator (por ejemplo, editor, ilustrador y traductor).
7	Fecha	DC.Date	Una fecha en la que el recurso se puso a disposición del usuario en su forma actual. Esta fecha no ha de confundirsecon la que pertenece al elemento Coverage, que sería asociada con el recurso solo en la medida en que el contenido intelectualestá de algún modo relacionado con esa fecha.
8	Tipo del Recurso	DC.Type	La categoría del recurso, por ejemplo página personal, romance, poema, minuta, diccionario. Para asegurar la interoperabilidad, Type debería ser seleccionado de entre unalista de valores que actualmente se encuentra bajo desarrollo en un grupo de trabajo.
8	Formato	DC.Format	El formato de datos de un recurso, usado para identificar el software y posiblemente, el hardware que se necesitaría para mostrar el recurso. Para asegurar la interoperabilidad, los valores de Format deberían ser seleccionados de entre una lista de valores que actualmente se encuentra bajo desarrollo en un grupo de trabajo.
10	Identificador	DC.Identifier	Secuencia de caracteres usados para identificar unívocamente un recurso. Ejemplos para recursos en línea pueden ser URLs y URNs (cuando estén implementados). Para otros recursos pueden ser usados otros formatos de identificadores, como por ejemplo ISBN (“International Standard Book Number” – Número Internacional Normalizado para Libros)
11	Fuente	DC.Source	Secuencia de caracteres utilizado para identificar unívocamente un trabajo a partir del cual proviene el recurso actual. Por ejemplo, es posible usar Source con la fecha de 1603 como descripción de una película basada en una obra de Shakespeare, pero es preferible, en ese caso, usar Relation “IsBasedOn” con una referencia a un recurso distinto cuyadescripción contenga el elemento Date con valor 1603.
12	Lengua	DC.Language	Lengua/s del contenido intelectual del recurso. Practicamente el contenido de este campo debería coincidir con los de la RFC 1766 (Tags para la identificación de lenguas, http://ds.internic.net/rfc/rf766.txt ); por ejemplo: en, es, de, fi, ja y zh.
13	Relación	DC.Relation	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.
14	Cobertura	DC.Coverage	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 (por ejemplo, sector celestial); uso de coordenadas (por ejemplo, longitud y latitud)o nombres de lugares extraidos de una lista controlada. La cobertura temporal se refiere al contenido del recurso en vez de a cuando fue creado o puesto accesible ya que este último pertenece al elemento Fecha.
15	Derechos	DC.Rights	Una referencia (URL, por ejemplo) 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. Una especificación formal del elemento Rights se encuentra actualmente en discusión y por lo tanto su uso se considera experimental.

Continuará…Similar Posts:

posted in Dublin Core by Tomás Vírseda Leave A Comment
©2010 Vazaar Project Blog. All Rights Reserved.

Extrayendo metadatos: libextractor

Sun, 02 Dec 2007 19:41:15 +0000

Para que Vazaar sea realmente útil debe extraer un alto porcentaje de metadatos que casi haga innecesaria la interacción del usuario. Hay una entrada en el wiki dedicada al análisis de utilidades y/o bibliotecas útiles para el proyecto. Ahora estoy probando con libextractor.

libextractor es una libreria cuyo fin es extraer metadatos de archivos de cualquier tipo. Se diseñó para utilizar otras liberias para ayudar en el proceso concreto de extraccion de metadatos, y tambien para que se pudiera ampliar facilmente su función con solo enlazar con extractores externos para tipos de archivo adicionales. libextractor es parte del proyecto GNU.

Lo interesante de esta herramienta es la cantidad de metadatos que es capaz de extraer. Este es un listado de los tags soportados por libextractor en mi sistema:

from extractor import Extractor
extractor = Extractor()
extractor.keywordTypes()
(‘unknown’, ‘filename’, ‘mimetype’, ‘title’, ‘author’, ‘artist’, ‘description’, ‘comment’, ‘date’, ‘publisher’,‘language’,
‘album’, ‘genre’, ‘location’, ‘version’, ‘organization’, ‘copyright’, ‘subject’, ‘keywords’, ‘contributor’,
‘resource-type’, ‘format’, ‘resource-identifier’, ‘source’, ‘relation’, ‘coverage’, ‘software’, ‘disclaimer’, ‘warning’,
‘translated’, ‘creation date’, ‘modification date’, ‘creator’, ‘producer’, ‘page count’, ‘page orientation’,
‘paper size’, ‘used fonts’, ‘page order’, ‘created for’, ‘magnification’, ‘release’, ‘group’, ‘size’, ‘summary’,
‘packager’, ‘vendor’, ‘license’, ‘distribution’, ‘build-host’, ‘os’, ‘dependency’, ‘MD4′, ‘MD5′, ‘SHA-0′, ‘SHA-1′,
‘RipeMD160′, ‘resolution’, ‘category’, ‘book title’, ‘priority’, ‘conflicts’, ‘replaces’, ‘provides’, ‘conductor’, ‘interpreter’,
‘owner’, ‘lyrics’, ‘media type’, ‘contact’, ‘binary thumbnail data’, ‘publication date’, ‘camera make’, ‘camera model’,
‘exposure’, ‘aperture’, ‘exposure bias’, ‘flash’, ‘flash bias’, ‘focal length’, ‘focal length (35mm equivalent)’, ‘iso speed’,
‘exposure mode’, ‘metering mode’, ‘macro mode’, ‘image quality’, ‘white balance’, ‘orientation’)

A pesar de la gran cantidad de metadatos que puede extraer no facilita manera alguna de saber con que tipo de metadato estás jugando. Según los creadores de esta librería, la mayor parte de los metadatos extraídos están basados en el vocabulario de Dublin Core. Sin embargo, otros metadatos han sido añadidos ante la necesidad de ciertos tipos de formato. Es decir, extrae un conjunto de parejas tipo clave/valor sin orden ni concierto dejando a la imaginación de los programadores la interpretación de los mismos.

En vazaar, MDX es el módulo encargado de la extracción de metadatos. Dado que libextractor está en la mayor parte de los sistemas y existen bindings para python me ha parecido razonable incluirlo. El mayor problema que estoy encontrando para implementarlo es la cantidad de tiempo que gasto buscando que significa cada cosa. Para ello estoy mapeando cada keyword de libextractor con su correspondiente elemento en Dublin Core. También tengo en cuenta los elementos cualificados:

# keyword['LIBEXTRACTOR KEYWORD-TYPE'] = (‘DC-ELEMENT’, ‘DC-TERM’)
keyword[‘album’] = (‘type’, ‘collection’)
keyword[‘aperture’] = (”, ”)
keyword[‘artist’] = (‘creator’, ”)
keyword[‘author’] = (‘creator’, ”)
keyword[‘binary thumbnail data’] = (”, ”)
keyword[‘book title’] = (‘title’, ”)
keyword[‘build-host’] = (”, ”)
…

Ejemplo del uso de MDX:

kaskaras@laptop:~/share/wc/vazaar/trunk/devel/swx$ python mdx.py screenshot.png
Adding item: screenshot.png
http://purl.org/dc/elements/1.1/description -> Created with GIMP
http://purl.org/dc/terms/modified -> 2007-11-01 22:04:54
http://purl.org/dc/elements/1.1/format -> image/png

Updated 19/XII/2009:
extract-metadata blueprint @ launchpad.netSimilar Posts:

Nepomuk (y II)

Sat, 01 Dec 2007 01:01:06 +0000

He estado leyendo más detenidamente acerca de Nepomuk y sus objetivos llegando a una conclusión muy clara: Nepomuk es más ambicioso que yo. Mientras que Nepomuk se centra en estructurar semánticamente un escritorio con un determinado modelo (PIMO), Vazaar es simplemente un almacen semántico de datos.

Leyendo las especificaciones podría ser interesante utilizar al menos un subconjunto de aquellas ontologías que realmente necesito (nrl, nie, nfo principalmente). Sin embargo, creo que lo voy a mantener lo mas simple posible centrándome en lo que es: un repositorio centralizado de datos y metadatos.

Algunos comentarios sobre Nepomuk

NRL: Según el abstract de la especificación, ha sido diseñado sobre las bases del lenguage de descripción de vocabularios RDF pero corrigiendo ciertas limitaciones de los actuales lenguajes de la Web Semántica. Dentro de unos meses me gustaría poder explicarlo con más detalle aunque si no he cogido mal el concepto se asemejaria al uso de las vistas en las bases de datos relacionales. Por un lado tienes el grafo y por otro lado las diferentes vistas que podrías crear del mismo (Named Graphs y Graph Views).
NAO: esta ontología permite relacionar de muchas maneras un recurso con otro así como adjuntar anotaciones, tags, identificadores.
NIE: Es la más interesante desde el punto de vista de mi almacén, vazaar. La descripción que hace de la misma es contundente: “The core of the NEPOMUK Information Element Ontology and the entire NIE Framework revolves around the concepts of DataObject and InformationElement. They express the representation and content of a piece of data. Their specialized subclasses can be used to classify a wide array of desktop resources and express them in RDF“.

Conclusiones:

Debido a la complejidad que puede añadir al proyecto el hecho de usar las ontologías y vocabularios que provee Nepomuk voy a optar por ceñirme al ámbito de Dublin Core. Al menos en una primera fase del proyecto. Con RDFS consigo una plataforma ampliamente aceptada e implementada por muchos servicios (swoogle por ejemplo) para consulta/intercambio de metadatos.Dejaré para otra entrada en este diario una explicación más amplia de que es RDF, RDFS, DC, .. y como lo usaré en el proyecto.
El uso de NIE implica que a mas bajo nivel enlaza con el resto de las ontologías y
En el caso de NAO y su “Generic Annotation Vocabulary” me parece algo confuso.
Tengo que estudiar más este tema. La teoría detras de Nepomuk es bastante interesante y podría aprovecharla para el proyecto. Pero la primera fase es aprender a manejarme con los triples, añadiendo, borrando y/o modificando, creando estructuras más complejas y aprender a relacionarlos. Y después representarlos. De nada sirve si el usuario no se puede aprovechar de esta inmensa cantidad de información de una forma práctica, sencilla e intuitiva.

Durante las interminables búsquedas me he encontrado con proyectos muy interesantes como Haystack o Gnowsys. Los dos, y basándose en conceptos similares a los de Nepomuk intentan llevar a la práctica un escritorio semántico. Y los dos, en mi humilde opinión, fallan en el cometido. El verdadero reto, la meta última sería que desde que el usuario entra en el sistema (gráfico) hasta que sale, debería estar haciendo uso de un escritorio semántico. Una aplicación aislada no sirve de mucho. Y Vazaar, de momento, es (será) una aplicación. Como Haystack y Gnowsys (pero en un futuro muy muy lejano, reemplazar a nautilus se me antoja posible).
Similar Posts: