instituto militar de engenharia metadados para - SE/8

Transcrição

INSTITUTO MILITAR DE ENGENHARIA
METADADOS PARA DOCUMENTAÇÃO E RECUPERAÇÃO
DE IMAGENS
POR
SIMONE DE SOUZA GARCIA
TESE SUBMETIDA
COMO REQUISITO PARCIAL
PARA A OBTENÇÃO DO GRAU DE
MESTRE EM CIÊNCIAS
EM SISTEMAS E COMPUTAÇÃO
Assinatura da Orientadora da Tese
____________________________________________
ANA MARIA DE CARVALHO MOURA - Dr. Ing.
Assinatura da Co-Orientadora da Tese
____________________________________________
MARIA LUÍZA MACHADO CAMPOS - Ph.D.
Rio de Janeiro – RJ
Fevereiro 1999
A Deus, por tudo...
À minha família,
em especial a meus pais Eranir e Marlene
e meus irmãos Cláudia e Fabio,
e todos os meus amigos.
AGRADECIMENTOS
A Deus, por ter me concedido essa oportunidade, me dando a saúde e a determinação
necessárias ao desenvolvimento desse trabalho.
Aos meus pais, pela grande dedicação, incentivo e contribuição na minha formação
como pessoa e como profissional.
Aos meus irmãos, pelo grande carinho e compreensão. Agradeço à minha irmã, por ter
suportado por várias vezes a luz do nosso quarto aceza durante à noite, além do barulho do
teclado do computador; e ao meu irmão, por ter respeitado os momentos em que eu estudava,
diminuindo o volume do som para que não me atrapalhasse.
Ao Exército Brasileiro, especialmente ao Instituto Militar de Engenharia, por ter me
acolhido e pela qualidade do curso ministrado.
Às professoras Ana Maria do IME e Maria Luíza da UFRJ, por todo o conhecimento e
incentivo transmitidos como professoras e orientadoras, assim como pela grande dedicação
para a realização desse trabalho.
À CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), por ter
me proporcionado a bolsa de estudos durante esse período em que fiquei estudando o
Mestrado.
À professora Marina Teresa da UFSCar, por aceitar participar da banca de professores
para avaliação desta Tese.
À Cássia Barreto, pela atenção e conhecimentos transmitidos sobre o tema metadados,
o qual ela já pesquisava antes de mim.
À professora Rosa Inês da UFF e à funcionária Cássia Mello da FUNARTE, pela
atenção e conhecimentos transmitidos relacionados a área de Ciência da Informação.
Ao pesquisador Artur Caetano da Universidade de Lisboa, pela atenção e
conhecimentos transmitidos via Internet com relação aos conceitos de histograma de cor,
textura, entre outras informações relevantes a esse trabalho.
Ao funcionário Vicente Perroni da empresa Computer Associates, pela atenção e
conhecimentos transmitidos com relação a utilização do Jasmine.
Ao professor Marcos Veloso do IME, pela atenção e dedicação durante o período de
configuração do ambiente necessário para utilização do WebLink com o Jasmine.
Ao Dirceu Vianna, pela amizade e ajuda proporcionada por meio de seu dom artístico
para o desenho dos botões utilizados nas páginas HTML do protótipo implementado.
Às bibliotecárias do IME, NCE e PUC, pela atenção em todas as vezes que precisei
fazer pesquisa bibliográfica.
A todos os professores, pelos conhecimentos transmitidos. E aos funcionários do
Departamento de Engenharia de Sistemas do IME pelo apoio, principalmente ao Sgt Messias
pelo apoio técnico do laboratório.
A todos os colegas de turma, pelo companheirismo e união durante esses dois anos de
intensos estudos. A todos os meus amigos e amigas, pelo carinho e forças durante esse
período.
Finalmente, a todos aqueles que direta ou indiretamente contribuíram na elaboração
deste trabalho.
RESUMO
Este trabalho foi desenvolvido com o propósito de desenvolver uma modelagem
conceitual que permita a descrição e recuperação de imagens, por meio do estudo e
sistematização das características de imagens. As classes pertencentes ao esquema conceitual
decorrente dessa modelagem viabilizam a documentação de uma imagem estática do tipo
fotografia, pintura ou gravura qualquer, descrevendo suas propriedades, os componentes
contidos na imagem e os relacionamentos existentes entre eles. Estes descritores permitem
também identificar os objetos imagem que são versões de outro objeto imagem e os tipos de
associações existentes entre os mesmos.
O esquema proposto descreve tanto as informações técnicas quanto as informações
relacionadas ao conteúdo semântico da imagem, contribuindo com uma especificação
sistemática e detalhada dos elementos descritores de imagens estáticas digitais, podendo com
isso serem utilizados em arquiteturas de metadados existentes.
Este esquema serviu como base para a implementação de um protótipo de aplicação
em um ambiente que possibilita a descrição e recuperação de imagens baseadas em seus
descritores, possibilitando ainda que as imagens sejam consultadas no ambiente Internet.
iv
ABSTRACT
The purpose of this work was to develop a conceptual modeling to describe and
retrieve images by the study and systematization of image features. The classes belonging to
the conceptual schema derived from this conceptual modeling represent static images of any
type such as: photograph, painting or any picture, describing its properties, and also making it
possible to describe components contained in the image and existing relationships among
them. These descriptors also allow the identification of image objects which are versions of
other image objects and the types of existing associations among them.
The considered schema takes into account not only technical information but also
information related to the semantic content of the image, providing a systematic and detailed
specification of the descriptor elements of static digital images, that can be used in any
existing metadata frameworks.
This schema has served as a basis for an application prototype implementation in an
environment that enables the description and retrieval of images based on their descriptors,
allowing also an image that can be queried in the Internet environment.
v
SUMÁRIO
RESUMO
iv
ABSTRACT
v
LISTA DE ILUSTRAÇÕES
x
LISTA DE TABELAS
xi
LISTA DE ABREVIATURAS E SÍMBOLOS
xi
1 - INTRODUÇÃO
01
1.1 - OBJETIVOS DA TESE
03
1.2 - ORGANIZAÇÃO DA TESE
04
2 - IMAGEM ESTÁTICA DIGITAL: CARACTERIZAÇÃO E ABORDAGENS
06
2.1 - CARACTERIZAÇÃO
07
2.2 - PROCESSAMENTO DE IMAGEM
10
2.3 - FORMATOS
12
2.3.1- Formato PNG
13
2.3.2- Formato SPIFF
15
2.3.3- Análise Comparativa dos Formatos
18
2.4 - O ESTUDO DA IMAGEM EM DIFERENTES ABORDAGENS
2.4.1- Recuperação da Informação (Information Retrieval - IR) em Imagem
20
20
2.4.1.1- Características
21
2.4.1.2- Exemplos
22
2.4.2- Banco de Dados de Imagem
24
25
2.4.2.2- Abordagem VIMS
26
2.4.2.3- Exemplos
28
vi
2.4.3- Técnicas de Inteligência Artificial Aplicadas à Recuperação de Imagem 31
32
2.4.3.2- Exemplo
33
2.5 - CONSIDERAÇÕES FINAIS
34
3 - PADRÕES E ARQUITETURAS DE METADADOS
3.1- PADRÕES
36
37
3.1.1- Dublin Core
37
3.1.2- SAIF
39
3.2 - ARQUITETURAS DE METADADOS
3.2.1- Arquitetura Warwick
41
41
3.2.1.1- Relacionamentos Ativos Distribuídos (DARs)
43
3.2.2- Arquitetura de Descrição de Conteúdo (MCF)
44
3.2.3- Arquitetura de Descrição de Recurso (RDF)
46
3.2.4- Arquitetura Segundo Chang e Zhang
47
3.3 - ARQUITETURA DE MODELAGEM SEGUNDO KERHERVÉ
49
3.4 - SISTEMAS UTILIZANDO METADADOS PARA IMAGEM
50
52
4 – MODELAGEM CONCEITUAL DE METADADOS PARA IMAGEM
55
4.1- VISÃO SEGUNDO A CIÊNCIA DA INFORMAÇÃO
56
4.2- CARACTERÍSTICAS
60
4.3- ESPECIFICAÇÃO DE CLASSES
61
4.3.1- Objeto Imagem
64
4.3.2- Imagem Original
66
4.3.3- Tipo de Associação
68
4.3.4- Conteúdo Semântico
68
vii
4.3.4.1- Componente
69
4.3.5- Tipo de Relacionamento
70
4.3.6- Representação Posicional
70
4.3.7- Representação Factual
71
4.3.7.1- Ser
71
4.3.7.2- Reino
71
4.3.7.3- Força da Natureza
72
4.3.7.4- Objeto
72
4.3.8- Componentes Integrantes
72
4.3.9- Componentes Não Integrantes
73
4.4 - EXEMPLOS UTILIZANDO O ESQUEMA
74
76
5 - VISÃO GERAL SOBRE O PROTÓTIPO PARA BUSCA DE IMAGENS
5.1- CRIAÇÃO DAS CLASSES E MÉTODOS NO JASMINE
5.1.1- Classes do Esquema Proposto e seus Métodos em ODQL
5.2- UTILIZAÇÃO DO WEBLINK COM O JASMINE
78
79
79
86
5.2.1- Arquitetura do WebLink
86
5.2.2- Templates do Protótipo
88
5.3- INTERFACE DE CONSULTA AOS METADADOS DAS IMAGENS
95
5.4- CONSIDERAÇÕES FINAIS
101
6 - CONCLUSÃO
103
6.1- PRINCIPAIS CONTRIBUIÇÕES
105
6.2- SUGESTÕES PARA TRABALHOS FUTUROS
106
APÊNDICE A - ALGUNS MÉTODOS EM ODQL
107
APÊNDICE B - ALGUNS ARQUIVOS HTML COM CÓDIGO ODQL EMBUTIDO
115
viii
APÊNDICE C - PROCEDIMENTOS PARA UTILIZAÇÃO DO JASMINE
123
APÊNDICE D - UTILIZAÇÃO DO ESQUEMA EM XML
128
REFERÊNCIAS BIBLIOGRÁFICAS
133
ix
LISTA DE ILUSTRAÇÕES
FIGURA 2.1: Modelo de Dados do VIMSYS
29
FIGURA 3.1: Recipiente
42
FIGURA 3.2: Exemplo de uso do DARs para gerenciamento de direitos
44
FIGURA 3.3: Quadro DLG representando dados MCF
45
FIGURA 3.4: Exemplos RDF
47
FIGURA 3.5: Arquitetura de Metadados
48
FIGURA 3.6: Arquitetura de modelagem segundo Kerhervé
49
FIGURA 4.1: Esquema Conceitual de Metadados para Imagem
62
FIGURA 4.2: Diagrama de Instâncias da figura exemplo 1
74
75
76
FIGURA 5.1: Classes do Esquema implementadas no Jasmine Studio
80
FIGURA 5.2: Método exemplo utilizando o comando stringCat()
81
FIGURA 5.3: Funcionamento do WebLink
86
FIGURA 5.4: Arquitetura WebLink
88
FIGURA 5.5: Tela exemplo de inclusão utilizando o Jasmine Studio
96
FIGURA 5.6: Primeira tela (inicial.html) da aplicação via Internet
97
FIGURA 5.7: Segunda tela (home.html) da aplicação via Internet
97
FIGURA 5.8: Tela (opcoes.html) com as opções de consulta da aplicação via Internet
98
FIGURA 5.9: Consulta à classe Componente (compo.html)
98
FIGURA 5.10: Resposta à consulta (resultcompo.html) feita na Figura 5.9
99
FIGURA 5.11: Resposta às associações (resultassoc-escolhido.html) da Figura 5.10
99
FIGURA 5.12: Consulta à classe Objeto_Imagem (obj_img.html)
100
x
FIGURA 5.13: Resposta à consulta (resultobjimg.html) feita na Figura 5.12
100
FIGURA C.1: Tela do WebLink Environment Editor
126
LISTA DE TABELAS
TABELA 2.1: Características técnicas dos formatos de arquivo
19
TABELA 3.1: Elementos do Padrão Dublin Core
39
TABELA 4.1: Categorias para a representação da imagem (SHATFORD, 1986)
59
TABELA 4.2: Legenda utilizada na representação da estrutura de classes do esquema
63
LISTA DE ABREVIATURAS E SÍMBOLOS
CCD
(“Contrast, Coarseness e Directionality”)
CGI
(“Common Gateway Interface”)
CMY
(“cyan, magenta, yellow”)
CODQLIE
(“Client ODQL Interactive Environment”)
CORBA
(“Common Object Request Brocker Architecture”)
DARs
(“Distributed Active Relationships”)
DC
(“Dublin Core”)
DLGs
(“Directed Linked Graph”)
DOS
(“Disk Operational System”)
FGDC
(“Federal Geographic Data Committee”)
ftp
(“file transfer protocol”)
xi
GIF
(“Graphics Interchange Format”)
BMP
(“Microsoft Windows Bitmap”)
GUI
(“Graphical User Interface”)
HSV
(“Hue, Saturation, Value”)
HTML
(“HyperText Markup Language”)
IA
Inteligência Artificial
IAFA/WHOIS++
(“Internet Anonymous Ftp Archive with Whois++ protocol”)
IR
(“Information Retrieval”)
JFIF
(“JPEG File Format”)
JPEG
(“Join Photographic Experts Group”)
MARC
(“Machine Readable Catalogue”)
MCF
(“Meta Content Framework”)
MNG
(“Multiple-image Network Graphics”)
OCR
(“optical character recognition”)
ODQL
(“Object Database Query Language”)
PNG
(“Portable Network Graphics”)
QL-DB
(“Query Language Database”)
QL-IR
(“Query Language Information Retrieval”)
RDF
(“Resource Description Framework”)
RGB
(“red, green, blue”)
SAIF
(“Spatial Archive and Interchange Format”)
SGBD
Sistema Gerenciador de Banco de Dados
SGBDOO
Sistema Gerenciador de Banco de Dados Orientado a Objetos
SGML
(“Standard Generalized Markup Language”)
SPIFF
(“Still Picture Interchange File Format”)
xii
SQL
(“Structured Query Language”)
Tag
Marcação
TEI
(“Text Encoding Initiative”)
TIFF
(“Tagged Image File Format”)
UML
(“Unified Modeling Language”)
URI
(“Universal Resource Identifier”)
URL
(“Universal Resource Location”)
VIMS
(“Visual Information Management Systems”)
VIR
(“Visual Information Retrieval”)
WWW
(“World Wide Web”)
XML
(“Extensible Markup Language”)
xiii
CAPÍTULO 1
INTRODUÇÃO
Com o lançamento da chamada segunda revolução da informação, estimulada pelo
aparecimento de ambientes multimídia, interações homem-computador estão sendo
transformadas. Informações multimídia crescem por todos os lados, em qualidade e
quantidade e muitas áreas da tecnologia da informação estão adotando plataformas, tipos de
dados e ambientes multimídia. Com toda essa informação emergente, cresce também em
importância o estudo de objetos multimídia e sua utilização com a tecnologia de banco de
dados.
A forma estruturada de armazenamento dos dados em banco de dados não permite
trabalhar adequadamente com objetos multimídia. Um problema ainda incomoda a quem
precisa gerenciar informações que incluam, além de texto, imagens estáticas, áudio e vídeo. A
dificuldade básica se refere à manipulação desses objetos, que normalmente possuem
características particulares a cada um. Além do simples armazenamento, é importante
conseguir disponibilizar informações de conteúdo semântico desses objetos, de forma a
facilitar sua recuperação.
Informações na forma digital podem ser distribuídas através da Web ou em redes
locais para serem usadas para diferentes propósitos, como por exemplo para fortalecimento de
recursos de ensino, pesquisa e diversão. Imagens digitais realizam a grande promessa de
prover amplo acesso à herança cultural do mundo (BESSER & TRANT, 1995).
Banco de dados de imagem tem sido uma área de grande importância em muitos
domínios e a tecnologia de hardware atual possibilita adquirir, armazenar, manipular e
transmitir grande número de imagens. Entretanto, falta ainda um meio mais natural de
consultar e acessar esses bancos de dados de imagem, já que em sua grande maioria, as
1
imagens armazenadas nos bancos de dados não são descritas de forma adequada. No mundo
de banco de dados fala-se muito sobre modelagem conceitual (semântica), a qual tenta
representar a semântica dos dados. A semântica de imagens é essencialmente extraída de seu
conteúdo, e a menos que exista um método efetivo e sistemático para identificar esses
conteúdos, o banco de dados irá degenerar para uma coleção de dados sem nenhuma
semântica.
Apesar do antigo ditado “Uma imagem vale mais do que milhares de palavras” ser
verdadeiro, existem informações importantes nas imagens que não podem ser percebidas sem
um conhecimento mais específico. Com isto surge a idéia de se ter descritores associados aos
dados contidos nas imagens, sendo estes descritores conhecidos como metadados.
O termo metadado, comumente definido como “dado sobre dados”, é utilizado em
função das necessidades das organizações em conhecerem melhor os dados que elas mantêm,
e com maior facilidade e detalhes os dados de outras organizações.
A finalidade principal dos metadados é documentar e organizar, de forma estruturada,
os dados das organizações com o objetivo de minimizar a duplicação de esforços e facilitar a
manutenção desses dados (PRABHAKARAN, 1997). Os dados precisam conter informações
que auxiliem seus usuários a tomarem decisões sobre a sua devida aplicação. Os metadados
incluem elementos de descrição do conteúdo dos dados e qualquer informação que seja
relevante para a recuperação dos seus conteúdos.
Podem ser destacadas as seguintes vantagens em utilização e disponibilização de
metadados: estabelecimento de padrões de dados diante da heterogeneidade de informações
contidas em rede, como por exemplo a Internet; facilidade e maior precisão na recuperação
das informações desejadas; troca de informações entre aplicações e organizações; utilização
das tecnologias na catalogação descritiva.
2
Existem diferentes padrões de metadados, cuja utilização depende das finalidades
distintas de informações às quais estão associados: FGDC (Federal Geographic Data
Committee) para descrição de dados geo-espaciais (FGDC); MARC (Machine Readable
Catalogue) para catalogação bibliográfica (HEERY, 1996); IAFA/WHOIS++ (Internet
Anonymous Ftp Archive with Whois++ protocol) para descrição do conteúdo e serviços
disponíveis em arquivos ftp (file transfer protocol) (DEUTSCH et alii., 1994); TEI (Text
Encoding Initiative) para representação de materiais textuais na forma eletrônica
(BURNARD, 1994); DC (Dublin Core) para catalogação de documentos eletrônicos na Web
(BROSS, 1997); SAIF (Spatial Archive and Interchange Format) para compartilhamento de
dados espaciais e espaço-temporais (SAIF);
No caso das mídias do tipo imagens digitalizadas ainda não existe um consenso na
área de Ciência da Computação nem na área de Ciência da Informação de como se descrever
os dados de forma padronizada.
1.1- OBJETIVOS DA TESE
O objetivo deste trabalho é propor o desenvolvimento de uma modelagem conceitual
que permita a descrição e recuperação de imagens, por meio do estudo e sistematização das
características de imagens. As classes pertencentes ao esquema conceitual decorrente dessa
modelagem deverão viabilizar a documentação de uma imagem estática do tipo fotografia,
pintura ou gravura qualquer, descrevendo suas propriedades, os componentes contidos na
imagem e os relacionamentos existentes entre eles. Estes descritores deverão permitir também
identificar os objetos imagem que são versões de outro objeto imagem e os tipos de
3
O esquema proposto deverá descrever tanto as informações técnicas quanto as
informações relacionadas ao conteúdo semântico da imagem, contribuindo com uma
especificação sistemática e detalhada dos elementos descritores de imagens estáticas digitais,
podendo com isso serem utilizados em arquiteturas de metadados existentes.
Este esquema será a base para a implementação de um protótipo de aplicação em um
ambiente que possibilite a descrição e recuperação de imagens baseadas em seus descritores,
possibilitando ainda que as imagens sejam consultadas por meio dos seus respectivos
metadados no ambiente Internet.
1.2- ORGANIZAÇÃO DA TESE
Além desse capítulo introdutório, o trabalho conta com outros cinco capítulos:
Capítulo 2: apresenta um estudo sobre imagem estática digital, explicando suas
características e abordagens. Contém três diferentes abordagens (Recuperação da Informação
- Information Retrieval - em Imagem, Banco de Dados de Imagem e Técnicas de Inteligência
Artificial Aplicadas à Recuperação de Imagem) encontradas na área de Ciência da
Computação para a recuperação de imagens e alguns formatos de arquivo de imagem que
possibilitam embutir metadados no próprio cabeçalho do arquivo.
Capítulo 3: estuda padrões e arquiteturas de metadados existentes na área de Ciência da
Computação.
Capítulo 4: especifica a proposta de um esquema conceitual de metadados para
documentação e recuperação de imagens, levando em consideração tanto as informações
técnicas da imagem quanto as informações de conteúdo semântico. As informações de
conteúdo semântico são embasadas em estudos realizados na área de Ciência da Informação.
4
Capítulo 5: descreve as principais diretrizes de especificação utilizadas no protótipo
implementado para documentar e recuperar imagens baseado no esquema definido no
Capítulo 4.
Capítulo 6: finaliza com a conclusão desse estudo, apresentando as suas principais
contribuições e sugestões para trabalhos futuros.
5
CAPÍTULO 2
IMAGEM ESTÁTICA DIGITAL: CARACTERIZAÇÃO E ABORDAGENS
Neste capítulo será apresentado o estudo relacionado à caracterização de imagens
estáticas digitais e as abordagens que tratam esse tipo de mídia, com o objetivo de identificar
suas principais propriedades visando a especificação de descritores para as mesmas.
Imagens estáticas digitalizadas são sequências de pixels que representam uma região
mostrada no monitor gráfico do usuário. Pixels são números interpretados para permitir a
exposição de um determinado ponto (“dot”) com valores diferentes para luminosidade, cor e
contraste. Pixels podem ser simples 0 ou 1, indicando branco ou preto para imagens estáticas
em preto-e-branco. Por outro lado, imagens coloridas de alta resolução podem conter 8, 16 ou
24 bits por pixel, permitindo a representação de milhões de cores. O espaço para
armazenamento de imagens estáticas varia de acordo com suas características de resolução,
tamanho, e esquema de compressão usado. Existe grande variância em qualidade e quantidade
de armazenamento requerido por imagens estáticas (KHOSHAFIAN & BAKER, 1996).
Um enfoque mais detalhado com relação à caracterização de imagens pode ser visto na
seção 2.1. Um resumo sobre processamento de imagens digitais está sendo apresentado na
seção 2.2. Na seção 2.3 podem ser vistos alguns formatos de arquivos para a mídia do tipo
imagem. E a seção 2.4 apresenta três abordagens (Recuperação da Informação - Information
Retrieval - em imagem, Banco de Dados de Imagem e Técnicas de Inteligência Artificial
Aplicadas à Recuperação de Imagem) da área de Ciência da Computação que tratam a
descrição e a recuperação da imagem de forma diferenciada.
6
2.1- CARACTERIZAÇÃO
Imagem é uma mídia que necessita ser descrita de tal forma que as informações
pertencentes a seu conteúdo possam ser entendidas. Em geral, o tratamento das informações
do escopo semântico da imagem não vem tendo a importância que merece, pois dados do tipo
imagem têm sido descritos como os demais tipos de arquivos que possuem tamanho, forma,
dentre outras informações meramente técnicas de um arquivo.
Para que o conteúdo semântico da imagem tenha o enfoque merecido, faz-se
necessário o estudo e entendimento mais específico do que vem a ser uma imagem digital, e
como ela pode e/ou deve ser adquirida e descrita, de forma a possibilitar o armazenamento de
características relacionadas ao seu conteúdo e forma.
As características da imagem relacionadas à descrição de conteúdo semântico, além
das suas características técnicas poderão ser vistas no Capítulo 4. Nesta seção serão
apresentadas algumas características consideradas informações técnicas da imagem, descritas
a seguir:
-
Formato
Especifica o formato padrão de armazenamento de arquivo, existindo uma variedade
de formatos padrões para armazenamento de arquivo imagem (incluindo TIFF, GIF, JFIF,
SPIFF, PNG, BMP, PICT, TGA, EPS, CGM, etc.).
-
Esquema de Compressão
Identifica o tipo de compressão utilizado na criação da imagem digital, já que existem
vários esquemas de compressão diferentes (tais como JBIG, LZW, QuickTime, etc.)
(BESSER & TRANT, 1995). Compressão de imagem é o processo de redução do tamanho do
arquivo da imagem através de métodos tais como: retirada de informação repetida ou
eliminação de informação difícil de ser detectada pelo olho humano. Existem dois tipos de
7
compressão de imagem: compressão com perda e compressão sem perda. Uma imagem
descomprimida e vista após a compressão sem perda será idêntica ao seu estado antes de ter
sido comprimida. A compressão sem perda normalmente reduz o armazenamento em 50%,
enquanto que a compressão com perda pode reduzir em até 96%. A compressão com perda
significa a perda de dados e consequentemente perda de qualidade.
-
Tipo de digitalizador
Identifica o tipo de dispositivo (scanner) utilizado para a digitalização da imagem, já
que existem diversos tipos (BESSER & TRANT, 1995): Copystand / Câmera Digital onde a
imagem após ter sido fotografada é digitalizada; Drum (tambor) no qual o material a ser
digitalizado é colocado em um tambor que é girado passando por uma luz de alta intensidade
que captura a imagem; Flatbed assemelha-se às máquinas de fotocópias e o material fonte é
colocado no vidro e capturado por vetores CCD; Slide utiliza a luz que passa através do slide
para capturar um vetor CCD; Digitalizador de vídeo (frame-grabber)/(capturador de quadro)
utiliza placas de circuitos que são colocadas dentro do computador anexado a uma câmera de
vídeo padrão gerando a imagem digitalizada; finalmente, Digitalizador de mão, muito popular
pelo baixo preço, digitaliza até quatro polegadas na faixa de largura, digitalizando a imagem
ao ser passado por sobre o material que contém a mesma.
-
Resolução
É definida pelo número de pixels em uma dada área da imagem digital. A resolução de
um arquivo imagem é sempre expressa como uma proporção, como por exemplo 1000 x
2000; uma matriz 640 x 480, por exemplo, é usada para caracterizar o aparecimento no
monitor. Já a resolução de impressão é expressa em termos de pontos por polegada (dpi - dots
per inch).
8
-
Espaço de cor
Identifica o tipo padrão de cores usadas (por exemplo: RGB (Red, Green, Blue), HSV
(Hue, Saturation, Value), CMYK (Cyan, Magenta, Yellow, Black), etc), na digitalização da
imagem.
-
Histograma de cor
Representa a distribuição das cores existentes na imagem digital, de acordo com cada
pixel. Suponha que a imagem tenha N cores; a idéia é responder a “quantos pixels a cor X tem
associados?”, isto é, contar os pixels referentes a uma dada cor.
-
Textura
Refere-se geralmente à repetição de elementos básicos chamados de texels. O texel
contém vários pixels, cuja distribuição pode ser periódica, quase-periódica ou randômica.
(JAIN & DORAI, 1997). Regiões com textura são formadas por padrões espacialmente
extensíveis baseadas em uma repetição de alguma célula unitária (subpadrão). Segundo
(MEYER, 1997) não existe uma definição simples e sem ambiguidades para o termo “textura”
e a razão para isso é o conceito fortemente intuitivo de textura, impossível de ser descrito em
uma definição textual. A textura é representada por meio de um vetor gerado
automaticamente por um algoritmo, como por exemplo os algoritmos conhecidos como
atributos CCD (Contrast, Coarseness e Directionality) de Tamura, transformada de Wold,
Modelo SAR (Simultaneous Auto-Regressive), RISAR (Rotation-Invariant SAR), MRSAR
(Multi-Resolution SAR), GLCM (Grey Level Co-ocurrence Matrix) e GMRF (Gaussian
Markov Random Field) (CAETANO et alii, 1998).
-
Brilho
È proporcional à integral do produto da curva e à função de eficiência de
luminosidade, esse cálculo é feito automaticamente por meio de um algoritmo gerando um
vetor (FOLEY et alii, 1990).
9
2.2- PROCESSAMENTO DE IMAGEM
Ferramentas de processamento de imagem são aplicações multimídia que possibilitam
ao usuário criar, realçar, segmentar e editar imagens mapeadas por bit. A forma básica para o
armazenamento de pixels é por bits. Por exemplo, com um byte por pixel é possível obter 256
cores. Uma imagem digital é representada como uma função de duas dimensões f(x,y), onde x
e y são os valores das coordenadas x e y de um pixel. A função f é o brilho da imagem naquele
ponto (valor do pixel).
Existem categorias ou domínios fundamentais de processamento de imagem digital
(KHOSHAFIAN & BAKER, 1996):
•
Realce e Restauração de Imagem: melhoram as propriedades visuais das imagens. Realce
livra a imagem de deformações e distorções; várias técnicas de filtragem removem ruídos
e borrões em uma imagem. Uma técnica popular de filtragem é a filtragem mediana, a
qual troca o nível de cinza de cada pixel em uma imagem pelo nível de cinza mediano dos
pixels circundantes;
•
Análise de Imagem: tem o objetivo de entender as características da imagem e as
características dos objetos que ela contém. Exemplos de características de imagem
incluem brilho, textura, e cor. Características dos objetos da imagem incluem forma,
tamanho e contorno. A análise de imagem sempre começa com segmentação que isola os
vários objetos na imagem;
•
Síntese de Imagem: cria imagens de imagens fonte ou de dados não imagens como dados
numéricos. Tomografia computadorizada é considerada como uma síntese de imagem; sua
aplicação primária é a medicina. A técnica consiste em reconstruir uma imagem usando
múltiplas projeções de imagens.
10
Reconhecimento de Objetos em Imagens
Para o reconhecimento de objetos em imagens existem alguns passos. O primeiro
passo antes do reconhecimento de padrões é o processo na análise da imagem chamado
segmentação, o qual particiona a imagem em vários segmentos, identificando objetos
candidatos para o subsequente reconhecimento. Através da segmentação torna-se possível
detectar limites e contornos de objetos, e isto é feito através da detecção de pixels
relacionados e descontinuidades em uma imagem. Algoritmos de segmentação também usam
similaridade, como por exemplo pixels da mesma cor.
O segundo passo é o reconhecimento de padrões e existem algumas técnicas, como
por exemplo redes neurais que são muito promissoras no reconhecimento de fala, caracter e
objeto em geral. Uma outra tecnologia é a OCR (optical character recognition)
reconhecimento ótico de caracter, muito utilizada na área de imagem e reconhecimento de
padrões.
Os aspectos do reconhecimento de objeto com relação a banco de dados multimídia
são (KHOSHAFIAN & BAKER, 1996):
-
Extração das características de objetos que poderão ser indexados e usados para
possibilitar consultas em aplicações de bancos de dados multimídia. Para grandes
volumes de dados de imagens e outros tipos de dados multimídia, o objetivo
geralmente é automatizar a extração de características. Os processos do sistema
reconhecem e automaticamente indexam os objetos. As características extraídas
são incorporadas no banco de dados;
-
Existência também de intervenção (humana) manual que é sempre necessária para
corrigir erros do sub-sistema de extração de características para introduzir termos
ou pesos, e atualizar outros atributos do objeto. Pesos podem também ser usados
em estruturas adicionais para processamento de consultas.
11
2.3- FORMATOS
Existem vários formatos de arquivo de imagem dentre os quais os mais conhecidos e
utilizados são: JPEG (Join Photographic Experts Group), GIF (Graphics Interchange Format),
BMP (Microsoft Windows Bitmap) e TIFF (Tagged Image File Format) (MURRAY &
VANRYPER, 1996).
JPEG: padrão desenvolvido pelo Joint Photographic Experts Group para compressão
de imagens estáticas, armazena a cor de todos os pixels através de um método de compressão
com perda, significando que sempre que uma imagem é gravada nesse formato perde-se
alguma informação. O tamanho do arquivo JPEG resultante é muito pequeno, porém os dados
que contém são sempre uma aproximação da imagem original. JFIF (JPEG File Interchange
Format) é um formato de armazenamento de arquivo para imagens comprimidas com o
algoritmo JPEG.
GIF: criado pela CompuServe, armazena imagens usando codificação indexada, onde
cada pixel é representado por um índice de inteiro dentro de uma paleta de cores. O tamanho
da paleta é limitado a 256 cores, fazendo com que o GIF seja mais adequado para imagens
que não contenham muitas gradações finas de cores. GIF usa uma técnica de compressão com
pouca perda que pode resultar em arquivos muito pequenos.
BMP: criado pela Microsoft, suporta até 24 bits para cor e as imagens são mais
frequentemente armazenadas sem compressão, resultando em arquivos de tamanho grande.
TIFF: originalmente desenvolvido pela Aldus Corporation, suporta até 24 bits para cor
e pode ser comprimido com algoritmos como: LZW, CCITT ou JPEG.
Dois desses formatos mais utilizados evoluíram para novos formatos, apresentando
características importantes para esse estudo. Os dois novos formatos são: PNG (Portable
Network Graphics), que é sucessor do formato GIF (Graphics Interchange Format), e o SPIFF
12
(Still Picture Interchange File Format), que é o substituto oficial para o formato de arquivo
JFIF (JPEG File Interchange Format) para armazenamento de dados JPEG.
Os dois formatos de arquivo de imagem que serão apresentados a seguir têm como
característica principal de relevância dentro do escopo desse estudo a possibilidade de embutir
metadados no cabeçalho do arquivo.
2.3.1- Formato PNG
PNG (Portable Network Graphics) (ROELOFS, 1997) é um formato de arquivo de
imagem que pretende ser não só o sucessor do formato GIF, como também o mais extensível
e livre. Os dois formatos PNG e GIF possuem uma característica importante que é a
possibilidade de dados textuais poderem ser armazenados dentro do arquivo da imagem, o que
significa uma forma de armazenar metadados.
Os objetivos para esse formato de imagem são (ROELOFS, 1997a): portabilidade, não
somente através de plataformas e sistemas operacionais, mas também através de softwares;
compressão sem perda; compatível com a rede na crescente era da WWW; criação de um
novo formato gráfico capaz de substituir o GIF.
PNG, endossado formalmente como padrão pelo W3C (World Wide Web
Consortium) em 1996, é um formato livre de patentes. Imagens PNG mapeadas em cores
tendem a ser 20 a 30 % menores do que GIFs. Esquema de entrelaçamento 2D do PNG é uma
boa melhora sobre o entrelaçamento de linhas simples do GIF. Talvez o maior ganho seja o
suporte do PNG para canal alpha, significando a existência de transparência variável em seus
pixels. Pixels GIF são muito transparentes ou muito opacos; pixels JPEG são sempre opacos;
pixels PNG podem ter tantos níveis de transparência parcial quantos forem os existentes.
13
Correção gamma é outro recurso do PNG. Uma imagem criada para parecer perfeita
em um certo sistema é marcada com valores gamma do sistema. Quando a imagem é
mostrada em um sistema diferente o software efetua um cálculo simples para equalizar os
valores gamma, o que significa dizer que a imagem suporta display automático com correção
de brilho e contraste.
Quando a especificação PNG foi criada, multi-imagens GIFs eram uma curiosidade, e
animações estavam completamente excluídas. Foi decidido que PNG seria um formato em
imagem simples. Entretanto, MNG (“Multiple-image Network Graphics”) (MNG, 1997) é
uma proposta de adição à família PNG, para armazenar e transmitir animações de múltiplas
imagens e composição de quadros (“frames”), que está sendo projetada pelos desenvolvedores
do PNG.
PNG já está sendo usado pela Microsoft no Internet Explorer 4.0 beta, Amaya, ANT
Fresco, Arena, Ariadna, Grail, MacMosaic, Omniweb, Voyager, Adobe Photoshop 4.0 e
Microsoft Office 97.
Um arquivo PNG pode armazenar texto no cabeçalho do arquivo imagem. Palavraschave são usadas para indicar o que cada string texto representa.
Um arquivo PNG consiste de uma série de pedaços (“chunks” - que nesse contexto
referem-se às diferentes partes do arquivo PNG) com as seguintes funcionalidades: assinatura
PNG; informações de layout; convenções de nomeação; algoritmo CRC (Cyclic Redundancy
Check). Esse arquivo é sempre iniciado por um pedaço IHDR (cabeçalho da imagem) e
terminado por um pedaço IEND (fim dos dados PNG).
Especificações dos pedaços:
- Pedaços críticos
IHDR (cabeçalho da imagem): largura, altura, tamanho em bits, tipo de cor, método de
compressão, método de filtragem, método de interlace; PLTE (paleta); IDAT (dados da
14
imagem): contém os dados de saída do algoritmo de compressão; IEND: marca o fim dos
dados PNG.
- Pedaços auxiliares (opcional)
cHRM (cromaticidade primária e ponto branco); gAMA (imagem gamma); sBIT (bits
significantes); bKGD (cor do fundo); hIST (histograma da imagem): frequência usada de cada
cor na paleta de cores; tRNS (tranparência): valores em cores RGB (red, green, blue); pHYs
(dimensões físicas em pixels); tIME (data da última modificação da imagem); tEXt (dados
textuais): palavra-chave, separador nulo, texto, título, autor, descrição, direitos autorais, data
da criação, software usado para criação da imagem, responsável legal, aviso de natureza de
conteúdo, fonte (dispositivo usado para criação da imagem), comentário; zTXt (dados textuais
comprimidos): recomendado para blocos de textos grandes contendo: palavra-chave,
separador nulo, método de compressão e texto comprimido.
- Pedaço de tipos adicionais
Definido como PNG-EXTENSIONS. Podem ser criados tipos adicionais nesse
pedaço, caso os tipos existentes nos pedaços anteriores não sejam satisfatórios à necessidade
do usuário.
2.3.2- Formato SPIFF
SPIFF (Still Picture Interchange File Format) (SPIFF, 1995), um novo padrão que
está sendo suportado por poucas aplicações, é o substituto oficial para o formato de arquivo
JFIF (JPEG File Interchange Format) para armazenamento de dados JPEG. SPIFF é um
formato de arquivo bitmap genérico definido pela ITU (International Telecommunication
Union) e ISO/IEC (International Standards Organization/International Electrotechnical
15
Commision) para armazenamento, compressão, e troca de cor ou escala cinza, imagens em
tons contínuos, e dados de imagem bitonais.
Quando o “Joint Photographic Experts Group” estabeleceu o padrão de compressão
JPEG em 1990, não foi criado um formato de arquivo padrão correspondente para armazenar
e trocar dados JPEG. O SPIFF foi então criado em 1995 para ratificar esta omissão do comitê
JPEG. O formato JFIF (JPEG File Format) foi criado em 1992 só que não tão bem projetado,
especificado nem flexível como o SPIFF.
SPIFF é um padrão oficial que estende características do JFIF incluindo suporte para
mais espaços de cores e uma cláusula para especificação de informações gamma da imagem.
Arquivos SPIFF são compostos de quatro seções principais: cabeçalho, diretório de
informação, dados de imagem, e dados indiretos (que são informações muito grandes para
caberem no diretório de informação).
A especificação do SPIFF não define um único padrão de extensão de arquivo ou
indicador de tipo. É recomendado que a extensão “.JPG” seja utilizada para arquivos SPIFF
contendo perda na compressão e “.SPF” seja utilizada para as outras variantes do SPIFF que
não contêm perda na compressão (MURRAY, 1996).
Constituem características do SPIFF: cores bitonais para 32 bits; tipos de compressão:
Modified Huffman, MR, MMR, JBIG, JPEG e uncompressed; tamanho máximo da imagem
de 4Gx4G pixels, 64kx64k pixels para JPEG baseado em linha não titulado; não possui
imagens múltiplas por arquivo; formato numérico Big-endian; utilizado em todas as
plataformas; e suportado por todas as aplicações que suportam formato JFIF.
O cabeçalho do SPIFF tem 36 bytes de tamanho com o seguinte formato:
typedef struct_SpiffHeader
{
DWORD MagicNumber;
WORD HeaderLenght;
CHAR Identifier (6);
WORD Version;
16
BYTE ProfileId;
BYTE NumberComponents;
DWORD ImageHeight;
DWORD ImageWidth;
BYTE ColorSpace;
BYTE BitsPerSample;
BYTE CompressionType;
BYTE ResolutionUnits;
DWORD VerticalResolution;
DWORD HorizontalResolution;
} SPIFFHEADER;
Nesse cabeçalho, MagicNumber é o valor de identificação para arquivos SPIFF.
HeaderLenght contém o tamanho do cabeçalho. Identifier contém valores de identificação
adicionais. Version contém a maior e a menor versão SPIFF do arquivo. ProfileId especifica
as características que o leitor deve suportar para ler o arquivo. NumberComponents indica o
número de componentes de cor (canais) na imagem primária (1- típica imagem em escala
cinza e 3 - para imagem RGB (red, green, blue) ou CMY (cyan, magenta, yellow)).
ImageHeight e ImageWidth armazenam o tamanho da imagem, ImageHeight é o número de
linhas digitalizadas na imagem primária e ImageWidth é o número de amostras por linhas.
ColorSpace especifica o sistema de coordenadas de espaço de cor usado para definir as
amostras. BitsPerSample especifica o número de bits por amostra. CompressionType indica o
tipo do algoritmo de compressão usado na codificação dos dados da imagem. ResolutionUnits
indica o tipo de unidade usada para expressar a resolução da imagem. VerticalResolution e
HorizontalResolution contêm a resolução da imagem.
Seguindo o cabeçalho existe um diretório (Directory Entry 1, Directory Entry 2,
Directory Entry N, EOD Entry, Image Data, Indirect Data) de referências para informações
armazenadas dentro do arquivo SPIFF. O diretório conterá ao menos um directory entry, o
End Of Directory (EOD Entry) que é mandatório, sendo que todas as outras entradas são
opcionais.
O cabeçalho de cada directory entry tem 12 bytes de tamanho com o seguinte formato:
17
typedef struct_SpiffDirectoryEntry
{
WORD EntryMagic;
WORD EntryLenght;
DWORD EntryTag;
} SPIFFDIRECTORYENTRY;
Nesse caso, EntryMagic identifica o início de cada directory entry e este valor é
sempre FFE8h. EntryLenght é o tamanho da entrada. EntryTag é um campo de identificação
de formato e tipo de dado armazenado ou referenciado por um directory entry.
Cada directory entry terá sempre um único valor de EntryTag e um formato específico
de dados de entrada. Nos directory entry as entradas ocorrem em ordem contígua após o
cabeçalho e antes dos dados da imagem. A última entrada no diretório é a entrada EOD (End
Of Directory) que marca o fim do diretório.
2.3.3- Análise Comparativa dos Formatos
A Tabela 2.1 apresenta, de forma sintetizada, algumas características existentes nos
formatos PNG, GIF e SPIFF (PNG, 1997) (BOUTELL et alii., 1997) (SPIFF, 1995)
(MURRAY, 1996).
No cabeçalho da imagem dos formato PNG e SPIFF existem informações técnicas
com relação à imagem. No PNG o pedaço denominado de cabeçalho da imagem (IHDR)
contém somente informações de largura, altura, tamanho em bits, tipo de cor, método de
compressão, método de filtragem e método de interlace; outros tipos de informação são
colocados em pedaços separados para cada um deles, e a informação textual é armazenada no
pedaço padrão texto (tEXt) com palavras-chave adequadas, podendo ser múltiplo.
No formato SPIFF está definido um tipo para o cabeçalho (SpiffHeader) do arquivo
contendo campos como tamanho do cabeçalho, identificador, versão, perfil da aplicação,
número de componentes de cores, número de amostras por linha, espaço de cor, número de
18
bits por amostra, tipo de compressão, unidade de resolução, resolução vertical e resolução
horizontal. Existe também a possibilidade de definir outros tipos considerados também como
cabeçalhos (SpiffDirectoryEntry) que contêm um ou mais campos, que podem ser opcionais.
Característica
Imagens coloridas indexadas de até 256 cores
Transparência
Display progressivo
Informação auxiliar: comentários textuais e outros dados podem ser
armazenados dentro do arquivo da imagem
Independência completa de hardware e software
Compressão sem perda
PNG
x
x
x
x
GIF
x
x
x
x
x
x
x
x
SPIFF
x
x
x
x
JPG SPF
x
(pouca
perda)
Imagens múltiplas em um arquivo (para animação)
Imagens em cores reais, até 48 bits por pixel
Imagens em escala cinza até 16 bits por pixel
Canal alpha completo para transparência geral
Informação gamma da imagem, a qual suporta display automático da
imagem com correção de brilho/contraste
Checagem automática de integridade de arquivo e detecção de erros
de transmissão
Completamente livre de patentes
Toolkit implementador padrão disponível
Benchmarks padrões disponíveis, pontos de referências p/
comparação
x
x
x
x
x
x
x
x
x
x
x
x
TABELA 2.1: Características técnicas dos formatos de arquivo.
O formato SPIFF possui uma especificação mais aberta e melhor estruturada do que o
formato PNG para tratamento desses dados. Esses podem ser colocados no cabeçalho,
possibilitando a definição de tipos de acordo com a necessidade da informação a ser
armazenada a partir do segundo cabeçalho (SpiffDirectoryEntry), pois o primeiro cabeçalho
(SpiffHeader) já tem o seu tipo definido.
Entretanto, o formato PNG possui vantagens técnicas a mais do que o SPIFF,
conforme podem ser observadas pela Tabela 2.1. Já existe uma proposta de adição à família
PNG denominado MNG (“Multiple-image Network Graphics”) objetivando armazenar e
transmitir animações de múltiplas imagens e composição de quadros (“frames”).
19
2.4- O ESTUDO DA IMAGEM EM DIFERENTES ABORDAGENS
Imagem digital é uma fonte rica e subjetiva de informação. Pessoas diferentes extraem
significados diferentes da mesma figura. Existe a necessidade de se tratar de forma
sistemática essa informação para que seus significados possam ser mais facilmente
armazenados.
A maioria das metodologias usadas para encontrar alguma interpretação de conteúdo
na imagem são ainda limitadas, devido a dificuldade das pesquisas que não utilizam ou não
consideram a semântica da informação em imagens. Tipicamente, estas metodologias
dependem de IDs de arquivos, palavras-chave, ou textos associados às imagens, e não
permitem consultar diretamente baseado nas propriedades visuais de imagens (FLICKNER et
alii., 1995).
Nesta seção serão mostradas as diferenças de tratamento da imagem dentro de três
diferentes abordagens da área de Ciência da Computação, a saber: Recuperação da
Informação - Information Retrieval - em Imagem, Banco de Dados de Imagem e Técnicas de
Inteligência Artificial Aplicadas à Recuperação de Imagem.
2.4.1- Recuperação da Informação (Information Retrieval - IR) em Imagem
A abordagem de recuperação da informação (IR) consiste na recuperação de todos os
documentos cujas propriedades são similares às apresentadas na consulta (RABITTI &
SAVINO, 1992). As técnicas para recuperação podem ser classificadas em duas: técnicas de
casamento exato e casamento parcial. A técnica de casamento exato apresenta a desvantagem
de não conseguir recuperar documentos cuja representação casa parcialmente, e por isto a
20
técnica de casamento parcial é mais poderosa no que diz respeito a eficácia do resultado das
consultas.
Em Information Retrieval a consulta pode ser melhorada, permitindo ao usuário
expressar explicitamente um grau de incerteza, e possibilitando a recuperação de imagens,
mesmo existindo um casamento parcial entre a consulta e a imagem existente.
Nesta abordagem existe a preocupação de possibilitar ao usuário a especificação de
consultas imprecisas para expressar o conhecimento incerto do conteúdo de imagens a serem
pesquisadas.
A tecnologia usada para recuperar imagens baseadas em informação visual é chamada
de Recuperação de Informação Visual (VIR – Visual Information Retrieval). A consulta por
conteúdo transforma a consulta do usuário em primitivas da imagem, que correspondem às
propriedades do interior da imagem (SHAH et alii., 1997).
Os componentes da consulta devem ter importâncias diferenciadas pelo usuário e a
regra associada ao componente da consulta pode ter diferentes preferências. Os valores de
preferência e de importância, combinados com o nível de reconhecimento dos objetos
correspondentes nas várias interpretações da imagem, podem ser usados para classificar as
imagens recuperadas.
A linguagem de consulta que permite a formulação de consultas imprecisas possibilita
também limitar o número de imagens recuperadas. Isto é possível pelo fato das imagens
recuperadas serem classificadas em ordem decrescente de relevância. A ordem é dada por
uma marcação associada a cada imagem. Esta marcação possibilita a medida do grau de
21
casamento entre cada imagem e a consulta. É obtida através da combinação dos valores de
preferência e importância associados a cada predicado na consulta especificada.
A linguagem de consulta adotada pela abordagem de recuperação da informação (QLIR) possui as seguintes características: não é baseada na lógica booleana; permite limitar o
número de imagens a serem recuperadas; permite associar valor de importância a cláusulas de
objetos diferentes; permite associar valor de preferência a regras posicionais diferentes.
A função de classificação que mede a relevância de cada imagem recuperada é
dependente do grau de reconhecimento de cada objeto presente na imagem, e dos valores de
importância e preferência de cada termo da consulta associados a cada regra posicional
verificada.
Sistemas de recuperação de informação visual (VIR – Visual Information Retrieval)
são classificados usando os seguintes critérios (CHANG et alii., 1997): automação,
características
multimídia,
adaptabilidade,
abstração,
generalidade,
categorização
e
processamento de domínio comprimido.
Uma característica dos sistemas VIR é o fato da pesquisa ser aproximada, requerendo
uma avaliação de similaridade visual. Os ítens retornados no topo da lista dos resultados da
consulta têm maior similaridade com relação a entrada da consulta. Mas os ítens retornados
raramente têm um casamento exato com os atributos especificados na consulta. Esses sistemas
podem também usar entrada humana direta e outros dados suportados para melhor indexar a
informação visual.
2.4.1.2- Exemplos
•
VIRAGE
A tecnologia VIR da Virage (GUPTA, 1997) suporta um conjunto de características
para recuperação de imagem com alto nível de precisão. Suporta várias propriedades de
22
imagem tais como cor, textura, estrutura, e composição. O mecanismo VIR é extensível,
possibilitando a adição de mais propriedades no conjunto constante disponível. A Interface de
Linha de Comando Virage (VCLI – Virage Command Line Interface) permite criar aplicações
que trabalham com outras aplicações ou sistemas, permitindo ao usuário analisar, ajustar
pesos e desempenhar buscas. VCLI recupera as imagens do banco de dados em tempo de
execução.
Virage desenvolveu um conjunto de ferramentas GUI (graphical user interface)
incluindo facilidades para inserção e consulta de imagem, ajuste de pesos para reconsulta,
caixas de diálogos para criação de campos para metadados e inclusão de chaves (VIRAGE,
1998). Virage utiliza o modelo do VIMSYS (apresentado na seção 2.4.2.3).
•
QBIC (Query By Image Content System)
QBIC, Consulta por Conteúdo de Imagem, é um sistema desenvolvido pela IBM que
permite fazer consultas a banco de dados baseadas no conteúdo visual da imagem (QBIC,
1997). Através dos vetores de características computadas de uma imagem, usa uma
abordagem baseada em similaridade. As consultas incluem também padrão SQL e predicados
de texto/palavra-chave. A interface gráfica de usuário permite a construção de consultas,
amostra de resultados múltiplos, a re-consulta baseada nas imagens retornadas, possibilitando
ainda a modificação e a re-consulta.
As características importantes são: técnica de indexação por características que
descrevem o conteúdo de imagem e vídeo; técnicas de segmentação automática para imagem
(para identificar objetos) e vídeos (para identificar objetos estáticos e em movimento e
tomadas de vídeo – conjuntos de quadros); e recuperação por similaridade (igualar percepção
humana).
Imagens e vídeos são processados para extrair características descrevendo seus
conteúdos que são armazenadas no banco de dados do sistema. Métodos identificam objetos
23
em imagens estáticas, segmentos de vídeo em sequências pequenas (chamadas de tomadas) e
características computadas descrevendo cor, textura, forma, posição, ou informação em
movimento. Na consulta ao banco de dados, imagens e segmentos de vídeo podem ser
recuperados através de exemplo (“mostre-me imagens semelhantes a esta imagem”) ou
através da seleção de propriedades. Permite também efetuar consultas baseadas em esboços e
desenhos construídos pelo usuário, padrões de cor e textura selecionados, objetos em
movimento e outras informações gráficas (FLICKNER et alii, 1995).
2.4.2- Banco de Dados de Imagem
O impulso para a origem de bancos de dados de imagem teve início com a
comunidade de interpretação de imagem (GROSKY et alii., 1992). Na década de 1990 as duas
comunidades, a de interpretação de imagem e a de banco de dados convergiram para uma
concepção comum devido à aceitação de que imagem e texto deveriam ser tratados
igualmente. Imagens devem também ser capazes de serem recuperadas por conteúdo e devem
ser componentes integrais de uma linguagem de consulta.
Um banco de dados de imagem é um banco de dados que armazena imagens e suporta
tipos de dados de imagem com um conjunto de funções associadas.
Quando pensamos em banco de dados de imagem temos que levar em conta que a
natureza de imagens como grandes estruturas de arquivo binárias requerem considerações
especiais em termos de suas estruturas, organização e capacidades de armazenamento.
24
O tratamento de dados (mídias) do tipo imagem e vídeo no ambiente de banco de
dados aconteceu primeiramente na arquitetura relacional e depois na arquitetura orientada a
objetos (GROSKY, 1997).
Após algumas experiências de trabalho com esses tipos de dados na arquitetura
relacional, foi descoberta uma limitação: o não casamento/combinação entre a natureza dos
dados e a forma que ambos o usuário e o sistema são obrigados a consultar e operar esses
dados. Abordagens de indexação padrão não funcionam para consultas baseadas em conteúdo
do dado multimídia.
O gerenciamento de dados multimídia em ambiente de banco de dados tem levado a
idéias conclusivas como: uma consulta multimídia tem que ser vista de maneira diferente da
consulta padrão de banco de dados e mais parecida com a consulta utilizada na abordagem de
“information retrieval”. Porém, esse conceito ainda não foi totalmente implementado em
banco de dados.
As representações lógica e física de objetos multimídia são definidas no modelo de
dados multimídia do domínio. Vários tipos de informação devem ser capturados no modelo de
dados multimídia: a estrutura detalhada dos vários objetos multimídia; propriedades e
operações dependentes de estruturas dos objetos multimídia; relacionamentos entre objetos
multimídia e objetos do mundo real; pedaços de objetos multimídia com representação de
relacionamentos entre eles e os métodos usados para determiná-los; propriedades,
relacionamentos e operações de objetos do mundo real.
O processo de recuperação em banco de dados de imagem deveria possuir a
característica de consultas imprecisas, até pelo fato de que no processo de recuperação da
imagem descrições semânticas poderão estar associadas a componentes da imagem e
25
múltiplas interpretações poderão ser geradas dependendo da descrição (RABITTI &
SAVINO, 1992).
A abordagem de banco de dados adota uma linguagem de consulta booleana, onde o
processamento da consulta é baseado no casamento exato entre a consulta e as imagens
recuperadas; além disso, não é possível medir a relevância das imagens recuperadas (não é
possível a listagem das imagens de acordo com uma ordem de relevância).
2.4.2.2- Abordagem VIMS
Abordagens denominadas VIMS (Visual Information Management Systems), Sistemas
de Gerenciamento de Informação Visual, que oferecem meios para recuperar imagens,
algumas vezes também são chamados de Sistemas de Banco de Dados Visuais (LORENZ,
1997).
Em Sistemas de Gerenciamento de Informação Visual (VIMS) a tarefa mais
importante é permitir ao usuário pesquisar pela informação. Duas classes de pesquisa são
reconhecidas (JAIN & GUPTA, 1996): - Pesquisa por Especificação: uma combinação de
palavras-chave que descreve informação semântica, atributos da imagem, propriedades de um
objeto da imagem, domínio de objetos definidos, medidas de domínio ou objetos imagens e
suas posições absolutas ou relativas; - Pesquisa por Exemplo: o sistema constrói os
parâmetros da consulta a partir de um objeto imagem exemplo podendo ser feita, por
exemplo, pela comparação de cor ou forma de uma imagem escolhida, ou até uma imagem
completa.
Nesta abordagem, Browsing é um modo de pesquisa navegacional, no qual a próxima
consulta é baseada nos resultados da consulta anterior. Enquanto a tarefa de pesquisa é
localizar uma imagem a partir de sua especificação parcial, um browser começa com uma
26
pequena especificação do usuário, possibilitando trocar os parâmetros da consulta
adicionando ou removendo restrições nas condições de pesquisa, trocando pesos em
consultas.
São características dos Sistemas de Gerenciamento de Informação Visual: as coleções
podem ser de domínio específico ou geral; suporte à abstração para manter explícito os
mapeamentos entre informação de níveis diferentes; modelo de dados flexível para que
existam meios de combinar características diferentes dentro de níveis de abstração diferentes;
velocidade no processamento da consulta; suporte a definição de dados para permitir ao
usuário definir os requisitos de suas coleções com flexibilidade.
O papel do modelo de dados em sistemas de banco de dados é prover uma linguagem
visual ou textual para expressar as propriedades de objetos de dados que serão armazenados e
recuperados. A linguagem de banco de dados deve permitir ao usuário definir, atualizar e
pesquisar objetos e propriedades. Para sistemas de gerenciamento de informação visual o
modelo de dados assume o papel adicional de especificar e computar níveis diferentes de
formas de abstração de imagens e vídeos. O modelo de dados necessita das seguintes
propriedades:
-
capacidade de acessar uma matriz de imagem completa ou em partes;
-
características da imagem devem ser consideradas entidades independentes e
também como relacionadas à imagem;
-
características da imagem devem ser ordenadas em uma hierarquia (as mais
complexas construídas acima das simples);
-
métodos alternativos devem existir para derivar uma característica semântica
específica das características da imagem;
-
o modelo de dados deve suportar dados espaciais e estruturas de arquivo que
infiram parâmetros espaciais associados às imagens e características das imagens;
27
-
no caso de regiões complexas da imagem as características da imagem devem ser
representadas como uma sequência de entidades aninhadas ou definidas
recursivamente.
O modelo de dados geral dos sistemas VIM está organizado em níveis. Em cada nível
todos os objetos têm um conjunto de atributos e métodos associados, onde os atributos têm
suas próprias representações e estão conectados a uma hierarquia de classe de atributo. As
relações podem ser espaciais, funcionais ou semânticas. O modelo original para o sistema
VIM é o modelo do VIMSYS, apresentado a seguir.
2.4.2.3- Exemplos
•
VIMSYS
VIMSYS (Visual Information Management Systems) é um Sistema de Gerenciamento
de Informação Visual, parte do projeto InfoScope da Universidade de Michigan (GUPTA et
alii., 1991). O objetivo do projeto VIMSYS é criar um sistema de gerenciamento de
informação que possa recuperar imagens ou partes de imagens além de dado textual. A ênfase
não está na interpretação das imagens, mas na organização de imagens e projeto de métodos
de acesso para responder as consultas.
O projeto VIMSYS pretende: estabelecer um relacionamento entre atributos
semânticos não computáveis de imagens e características computáveis desses atributos;
desenvolver uma metodologia para organizar e indexar as imagens e informações relacionadas
a imagem, levando em consideração atributos semânticos através da associação expressa no
item anterior; formular uma medida de similaridade para comparação quantitativa entre os
atributos semânticos.
O modelo de dados, representado pela Figura 2.1, foi desenvolvido em quatro planos
diferentes de entidades de informação que são: objetos domínio e relações (DO), eventos
28
domínio e relações (DE), objetos imagem e relações (IO), e representações de imagem e
relações (IR). Todos os objetos têm um conjunto de atributos e métodos associados. As
relações podem ser espaciais, funcionais ou semânticas.
FIGURA 2.1: Modelo de Dados do VIMSYS.
-
Plano IR (representação de imagem): uma representação de imagem é um tipo abstrato de
dado para cada objeto imagem no plano IO. Podem existir múltiplas representações de
imagem para cada objeto imagem.
-
Plano IO (objetos imagem): nesse plano existem três classes básicas de objetos: imagens,
características de imagem e organização da característica. Esse nível está dividido em dois
sub-níveis: sub-nível de segmentação e sub-nível de característica.
-
Plano DO (objeto domínio): especificação da semântica de nível das entidades domínio.
Os objetos são conectados através de um grafo objeto-relação, onde qualquer objeto pode
ser uma subclasse ou protótipo de um ou mais objetos no plano IO.
-
Plano DE (evento domínio): representa eventos definidos sobre sequências de imagens,
com o propósito de permitir que eventos computados de sequências de imagens ou vídeos
sejam entidades consultáveis.
29
•
AMORE
Amore (Advanced Multimedia Oriented Retrieval Engine) é um sistema de
recuperação de imagens em banco de dados de imagens desenvolvido pela NEC (AMORE,
1998). Nele as imagens podem ser recuperadas por meio de palavras-chave, por categoria
temática, por similaridade visual ou por similaridade semântica.
O banco de dados de imagem está dividido em seis categorias temáticas diferentes
(arts, movies, sports, travel, vehicles, wildlife) para permitir a pesquisa por similaridade
semântica (por exemplo, quando se quer pesquisar imagens semanticamente similares à
imagem que está selecionada, ele recupera as imagens que estão classificadas na mesma
categoria que a imagem selecionada). Existe também a possibilidade de pesquisa diretamente
por categoria temática (por exemplo, quando é escolhida uma das categorias aparecem todas
as imagens referentes a ela).
A similaridade visual trata somente os aspectos de cor e forma da imagem
determinados na condição da consulta, verificando se estas são similares aos determinados nas
imagens armazenadas. Essa similaridade de cor e forma é medida através de termos como
“Not Important”, “Little Important”, “Important” ou “Very Important”, que são escolhidos
como condição para a consulta.
•
EXCALIBUR
Excalibur Visual RetrievalWare (EXCALIBUR) é um sistema desenvolvido pela
Excalibur Technologies Corporation, que permite recuperar e indexar automaticamente dados
visuais. Usuários podem submeter consultas usando exemplos de dados visuais ou
descrevendo uma definição do tipo de imagem a ser consultada de acordo com a cor, textura,
forma e brilho, onde a cada um desses atributos pode ser associado um grau de importância
relativa.
30
A importância desses atributos é definida por meio de uma escala que vai de 0 (zero) a
5 (cinco), significando que o mais importante é definido como 5 e o que não tem importância
para a consulta é definido como 0 (zero).
A Excalibur Technologies Corporation, por meio de uma parceria feita com a
Computer Associates, fabricante do Banco de Dados Orientado a Objetos Jasmine (CAI,
1998), desenvolveu esse sistema denominado Excalibur Visual RetrievalWare, utilizando o
Jasmine para o armazenamento das imagens.
2.4.3- Técnicas de Inteligência Artificial Aplicadas à Recuperação de Imagem
A Inteligência Artificial, como as abordagens apresentadas anteriormente, também
permite tratar dados do tipo imagem, e as técnicas usadas, na grande maioria, são para
descrição e recuperação das características das imagens de forma automática.
O objetivo fundamental da Inteligência Artificial (RICH & KNIGHT, 1993) é
construir programas que resolvam problemas difíceis para o ser humano. No coração da
inteligência artificial está a hipótese do sistema de símbolos físicos possuir os meios
necessários e suficientes para a ação inteligente em geral. As evidências para a sustentação da
hipótese do sistema de símbolos físicos vêm não apenas de áreas como jogos, mas também de
áreas como a percepção visual, onde é maior a tentação de suspeitar-se da influência de
processos subsimbólicos. Modelos subsimbólicos, são por exemplo, as redes neurais. Esta
hipótese forma a base da crença de que é possível criar-se programas que executam tarefas
inteligentes, que no momento são realizadas por pessoas.
31
Dentro dessa abordagem pode ser verificado que as características de descrições de
imagens são geradas automaticamente através de técnicas de inteligência artificial (IA), como
por exemplo, redes neurais. Essas informações podem então ser colocadas em um banco de
dados.
Três técnicas importantes de IA são: busca – proporciona um meio de solucionar
problemas para os quais não existe disponível uma abordagem mais direta nem uma estrutura
na qual qualquer técnica direta disponível possa ser inserida; uso do conhecimento –
proporciona um meio de solucionar problemas complexos, explorando as estruturas dos
objetos envolvidos; abstração – proporciona um meio de separar características importantes e
variações das muitas características irrelevantes.
No estudo de (MEYER, 1997) podem ser identificadas técnicas de IA para o
tratamento de imagens. O principal enfoque de seu estudo é a classificação e utilização de
descritores de texturas de imagens e sua aplicabilidade na recuperação de imagens por
conteúdo em bancos de dados relacionais. Pode ser observado que o reconhecimento e a
extração de características com relação às texturas de imagens são feitos automaticamente,
utilizando a técnica de redes neurais, especificamente treinadas para este propósito.
Redes neurais (arquiteturas conexionistas) são dispositivos de processamento
distribuído baseados na operação do cérebro e no funcionamento de neurônios biológicos.
Elas são compostas de muitos elementos de processamento paralelos interconectados, onde
cada um desempenha operações numéricas simples e comunica seus resultados para seus
vizinhos através de conexão ponderada. Ajustando os pesos nestas conexões a rede pode ser
feita para alterar sua resposta para padrões particulares. Redes neurais não são programadas
32
diretamente, mas por um algoritmo de aprendizado, cujo objetivo é encontrar o conjunto de
pesos ótimos, e assim a resposta requerida para um problema particular.
2.4.3.2- Exemplo
•
IRIS
IRIS (Image Retrieval for Information System) é um sistema para recuperação baseado
no conteúdo de imagens, desenvolvido na Universidade de Bremen pelo grupo de Inteligência
Artificial (HERMES et alii., 1995). Esse projeto combina métodos e técnicas de computação
visual e Inteligência Artificial de modo a gerar descrições de conteúdo das imagens em uma
forma textual automaticamente.
O Sistema IRIS consiste de dois módulos: o módulo de análise da imagem (para
construir o banco de dados), e o módulo de recuperação da imagem. O módulo de análise da
imagem consiste de quatro sub-módulos: três módulos extraem cada um características de cor,
textura e contorno, e o quarto módulo é responsável pelo reconhecimento do objeto.
Para a extração de características de cor é feita a segmentação da imagem baseada na
cor e para cada elemento é computado um histograma de cor. Para a extração de
características da textura é feita a segmentação da imagem baseada na textura, e os valores
calculados são as entradas de uma rede neural retro-propagável que classifica a textura. A
descrição de forma, baseada em contorno, consiste de três passos: detecção de borda baseada
no gradiente, determinação de contornos de objeto, e análise de forma. A análise de forma
resulta em uma lista de parâmetros de região que serão dados ao modelo através de
reconhecimento do objeto.
Todas as anotações baseadas na cor, textura, contorno e reconhecimento de objeto são
geradas automaticamente. O módulo de recuperação da imagem é baseado na semântica
usando conceitos de linguagem natural.
33
Após a análise das três abordagens estudadas nesse capítulo (Recuperação da
Inteligência Artificial Aplicadas à Recuperação de Imagem) algumas considerações
importantes podem ser feitas com relação ao tratamento da imagem:
Information Retrieval (IR) em imagem, ou VIR (Visual Information Retrieval) –
recuperação de informação visual, preocupa-se com o tratamento das informações subjetivas
existentes na imagem. Adota uma linguagem de consulta (QL-IR) que permite expressar
incerteza na composição de imagens a serem pesquisadas, através da representação da
consulta utilizando valores de importância e preferência, existindo casamento parcial entre a
consulta e a imagem existente.
Banco de Dados de Imagem, ou banco de dados visuais, leva em consideração as
diferentes interpretações da imagem e diferentes níveis de reconhecimento dos componentes
da imagem. Entretanto, adota essencialmente uma abordagem de banco de dados pois usa uma
linguagem de consulta booleana. O processamento da consulta (QL-DB) é baseado no
casamento exato entre a consulta e as imagens recuperadas, e não é possível medir a
relevância das imagens recuperadas. A preocupação maior está no grau de flexibilidade e
abstração para a elaboração do modelo de dados do sistema, que possibilitará o gerenciamento
da informação visual. Caso haja a possibilidade de especificar-se consultas imprecisas em um
sistema deste tipo, isto poderá aumentar significativamente a eficácia do processo de
recuperação em banco de dados de imagem.
Técnicas de Inteligência Artificial Aplicadas à Recuperação de Imagem utilizam como
principal enfoque a geração automática das características que descrevem a imagem, e
geralmente essas características são relacionadas às informações técnicas da imagem.
34
Com relação às abordagens estudas nesse capítulo verifica-se, de certa forma, o uso de
elementos descritores para a representação das características das imagens, embora ainda não
sistematicamente organizados e especificados. Por exemplo, o sistema VIMSYS define planos
diferentes para a representação das informações das imagens, mas não define com detalhe
quais elementos fazem parte de cada um desses planos; e com relação aos outros sistemas
estudados, todos especificam elementos descritores, mas não se preocupam em identificar
esses elementos de forma a abranger grande número deles, que incluam tanto elementos para
descrever as informações técnicas da imagem como para descrever as informações de
conteúdo semântico da imagem.
Uma outra forma de armazenamento de metadados com relação à imagem foi
apresentada na seção 2.3, a qual possibilita embutir metadados no próprio cabeçalho do
arquivo. Fizeram parte desse estudo os dois formatos de arquivo de imagem (PNG e SPIFF).
O próximo capítulo apresenta o estudo de padrões e arquiteturas de metadados,
importantes para a compreensão do enfoque apresentado nesta Tese.
35
CAPÍTULO 3
PADRÕES E ARQUITETURAS DE METADADOS
Segundo (KERHERVÉ, 1997), as pesquisas relacionadas a metadados devem agora ir
em direção à integração e interoperação de proposições e padrões existentes. As pesquisas
nesta direção incluem questões de projeto e desenvolvimento de: modelos de metadados
extensíveis que possam ser adaptados a domínios de aplicação específicos; ferramentas
permitindo integração e interoperação de conjunto de metadados oriundos de diferentes fontes
e representados a partir de padrões diferentes; gerenciadores de metadados extensíveis
oferecendo serviços básicos de suporte a funções essenciais tais como acesso, transferência,
descoberta ou análise para o desenvolvimento de aplicações específicas.
Estes direcionamentos requerem um trabalho importante de modelagem de metadados,
e mais especificamente, de níveis de modelagem e metamodelos correspondentes. O
metamodelo para metadados significa os conceitos usados para definir o modelo de
metadados.
Para atender a estes requisitos de integração e interoperação, a literatura de metadados
utiliza os termos padrão, modelo e arquitetura. Esse trabalho não leva em consideração uma
definição nítida entre os termos padrão e modelo, uma vez que na literatura esses conceitos
ainda se confundem. Modelos de metadados são requeridos para descreverem o conteúdo e a
semântica dos dados em qualquer domínio de aplicação. Basicamente, todos os padrões de
metadados são modelos que, a partir de um consenso das comunidades de pesquisa passaram
a ser utilizados como padrões. Geralmente, esses padrões contêm elementos descritores de
dados específicos que são dependentes das finalidades distintas de informações que
armazenam. O papel das arquiteturas de metadados é descrever o ambiente de forma a prover
36
a interoperabilidade entre os vários padrões de metadados existentes. Metadados também
denominados descritores de dados podem ser definidos a nível de pixel ou a nível semântico.
Neste capítulo, será feito um estudo de padrões de metadados mais relacionados a
imagem, que permitem de alguma forma descrever imagens. Serão apresentadas também as
arquiteturas de metadados existentes e uma arquitetura de modelagem, seguido de exemplos
de sistemas que utilizam metadados para imagem.
3.1- PADRÕES
Esta seção apresenta o estudo de dois padrões de metadados que possibilitam a
descrição de imagens, porém não são totalmente adequados à descrição mais eficiente de
imagens, pois não viabilizam descritores para todas as suas características importantes.
3.1.1 - Dublin Core
O Dublin Core Metadata Element Set, ou simplesmente Dublin Core (DC) (BROSS,
1997), foi definido inicialmente como um conjunto de treze elementos básicos propostos no
primeiro workshop organizado em 1995 pelo OCLC (Online Computer Library
Center)/NCSA (National Center for Supercomputer Applications) (WEIBEL et alii., 1995),
com o objetivo de desenvolver um registro de metadados para descrever informação
eletrônica na rede. Ficou definido que documento (DLOs - Document like objects) seria o
elemento principal para descrever recursos de informação na rede. Apesar de um documento
do ambiente Internet poder ser composto de textos, imagens, áudio, vídeo ou até outro
hiperdocumento, um documento deveria ser considerado como um objeto global. O principal
37
objetivo desse padrão é identificar e definir um conjunto de elementos de metadados para
definir os recursos na Web.
No workshop de metadados para imagem CNI (Coalition for Networked
Information)/OCLC (MILLER, 1996), acontecido em setembro de 1996, os elementos do
conjunto de dados iniciais do DC foram modificados para incluir requisitos de que servem
para descrever tanto texto como imagem tais como um campo para descrição de conteúdo
(DC.description) e um campo para descrição de direitos autorais (DC.rights). Ficando o
Dublin Core com 15 elementos descritores.
O workshop chamado “W3C Workshop on Distributed Indexing and Searching”
(WEIBEL, 1996), que aconteceu em maio de 1996, resultou em uma proposta para embutir
metadados em HTML.
O 4o Workshop Dublin Core, que aconteceu em março de 1997, em Canberra (HEERY
et alii., 1997), continuou discutindo questões relacionadas aos elementos e sintaxe do Dublin
Core, e formalizou qualificadores adicionais (“The Canberra Qualifiers”): LANGUAGE
(especifica a linguagem para o valor do elemento do campo descritor; geralmente o padrão
tem sido Inglês), SCHEME (especifica um contexto para a interpretação de um determinado
elemento), TYPE (especifica o tipo de um determinado campo e é visto como um nome de
sub-elemento).
O exemplo encontrado em (MOURA et alii., 1998) mapeia o Dublin Core em HTML:
<HEAD>
<TITLE>Metadata: The Essential ....</TITLE>
<META NAME=“DC.title”
CONTENT=“(TYPE=short) Metadata: The Essential....”>
<LINK REL=SCHEMA.dc HREF=“http://purl.org/metadata/dublin_core_elements #title”>
<META NAME=“DC.subject” CONTENT=“(TYPE=keyword) metadata, resource description, ....”>
<LINK REL=SCHEMA.dc HREF=“http://purl.org/metadata/dublin_core_elements #subject”>
<META NAME=“DC.autor”
CONTENT=“(TYPE=name) Moura, A.M.C”>
<LINK REL=SCHEMA.dc HREF=“http://purl.org/metadata/dublin_core_elements#author”>
<META NAME=“DC.date”
CONTENT=“(TYPE=creation)(SCHEME=ISO31)1997-07-30”>
<LINK REL=SCHEMA.dc HREF=“http://purl.org/metadata/dublin_core_elements#date”>
<META NAME=“DC.autor” CONTENT=“(TYPE=email) [email protected]”>
</HEAD>
<BODY>
38
Na Tabela 3.1 a seguir estão apresentados os quinze elementos do Dublin Core
(BROSS, 1997):
DC.subject
DC.description
DC.title
DC.author
DC.publisher
DC.contributors
DC.date
DC.type
DC.format
DC.identifier
DC.source
DC.language
DC.relation
DC.coverage
DC.rights
Assunto: tópico, gênero, ou frases descritivas.
Texto descrevendo o conteúdo do recurso.
Título.
Principal criador.
Agência responsável pela disseminação (por exemplo: instituição
hospedeira).
Outras pessoas responsáveis por aspectos da página.
Data da última atualização: YYYYMMDD
Tipo de recurso: documento.
Formato: texto/html.
URL ou outros identificadores. Pode incluir ISBN.
Fonte original, se originalmente publicado em formato de paper.
Código 3-letras para linguagem da página.
(Sob desenvolvimento; pretende ligar, por exemplo gráfico a página
principal)
A localização espacial e/ou características de duração temporais do
objeto. (em desenvolvimento)
nota de direitos autorais.
TABELA 3.1: Elementos do Padrão Dublin Core.
3.1.2 - SAIF
O padrão SAIF (“Spatial Archive and Interchange Format”) foi desenvolvido como
um meio de compartilhar dados espaciais e espaço-temporais, permitindo descrever imagens
relacionadas a dados geo-espaciais. SAIF foi aprovado em 1993 pelo CGSB (Canadian
General Standards Board) como um padrão nacional no Canadá. Os principais objetivos do
SAIF são (SAIF):
• Manipular virtualmente qualquer tipo de dado geográfico;
• Endereçar tempo de forma que eventos e relacionamentos temporais possam ser
manipulados;
39
• Direcionar requisitos de gerenciamento de dados (tais como suporte a atualizações,
habilidade para integrar dados multimídia, habilidade para interfacear consultas a
bancos de dados);
• Ser apropriado para realizar operações eficazes em ambientes de rede;
• Harmonizar-se com os novos desenvolvimentos de bancos de dados SQL e
iniciativas do “Open GIS” (Padrão para Sistemas de Informação Geográficos);
SAIF é capaz de tratar dados geográficos como qualquer outro tipo de dado simples.
Introduz um número de construções espaciais e temporais. A informação de metamodelo do
SAIF enfatiza a estrutura de dado de objetos, expressa através de um paradigma orientado a
objeto.
No modelo SAIF, a informação é considerada como uma série de objetos, cada um de
um determinado tipo ou classe, onde:
- Objeto Geográfico: um objeto representando um fenômeno do mundo real o qual
existe em um domínio espacial ou espaço-temporal.
- Objeto Espacial: um objeto geográfico definido em uma região no espaço. Aquela
região é representada por um objeto espacial por meio de dois aspectos: geometria e
referenciamento espacial. A geometria define a forma do objeto e é determinada em
termos de pontos, linhas, conceitos de área e volume. Referenciamento espacial provê
a definição marcando o sistema de coordenadas e os sistemas de referência horizontal
e vertical.
- Objeto Espaço-temporal: considera um objeto geográfico definido como uma região
em ambos espaço e tempo. Esta região é representada por um objeto espaço-temporal
através de quatro aspectos de um domínio: geometria, referenciamento espacial,
tempo e referenciamento temporal.
40
Para descrever as definições de classes SAIF é utilizada a CSN (“Class Syntax
Notation”), notação de sintaxe de classes. E OSN (“Object Syntax Notation”) notação de
sintaxe de objetos, é a linguagem usada para construir representações legíveis de instâncias
dos objetos descritos pelo modelo de dados SAIF. Juntas podem ser consideradas como uma
linguagem de definição de dados, denominada SAIFtalk (SAIFtalk = CSN + OSN).
3.2- ARQUITETURAS DE METADADOS
Nesta seção serão apresentadas algumas arquiteturas de metadados encontradas na
literatura que fazem parte do conjunto das mais importantes e conhecidas. As arquiteturas de
metadados descrevem o ambiente de forma a prover a interoperabilidade entre os vários
padrões de metadados existentes.
3.2.1- Arquitetura Warwick
O grupo de trabalho Dublin Core criou uma infra-estrutura chamada de Arquitetura
Warwick (Warwick Framework) (DEMPSEY & WEIBEL, 1996) que tem o objetivo de
agregar pacotes de metadados distintos. A arquitetura suporta administração autônoma e
acessa pacotes de metadados de padrões diferentes (por exemplo: registro baseado em Dublin
Core pode ser um pacote, e SAIF pode ser outro).
Esta arquitetura deve ser modular para permitir que novos metadados sejam criados,
referenciados e associados a outros.
Os componentes básicos da arquitetura são:
- Recipiente: unidade básica onde conjuntos de metadados tipados (os pacotes) são agregados.
41
- Pacote: conjunto de metadados tipados representando um objeto de primeira classe. O
conteúdo do pacote é simplesmente considerado uma sequência de bits. Eles podem ser
divididos em 3 categorias:
• primitivo: formato de metadado primitivo definido separadamente. Podem ser
registros Marc, DC, e outros;
• indireto: referência a um objeto externo. A marca da referência é um objeto de
primeira classe, e pode ter seu próprio metadado e condições para acesso.
• recipiente: coleção de objetos metadados, os quais podem ser pacotes ou outros
recipientes.
A Figura 3.1 mostra um exemplo de recipiente, onde os dois primeiros pacotes estão
fisicamente no recipiente e o último, que define termos e condições para acessar um objeto, é
referenciado no recipiente indiretamente através da URI (Universal Resource Identifier).
FIGURA 3.1: Recipiente
Abaixo, apresenta-se um exemplo da implementação da Arquitetura Warwick em
HTML (MOURA et alii, 1998). Esta implementação propôs as marcas META e LINK do
HTML 2.0 para ser usada para embutir metadados e referenciar uma autoridade de esquema
(DC por exemplo), descrevendo um documento:
<HEAD>
<TITLE>Metadata Support to Internet Resources Description... </TITLE>
<META NAME=“package”
CONTENT=“(TYPE=begin) Dublin Core”>
<META NAME=“DC.title”
CONTENT=“(TYPE=short) Metadata Support....”>
<LINK REL=SCHEMA.dc HREF=“http://purl.org/metadata/dublin_core_elements #title”>
<META NAME=“DC.autor”
CONTENT=“(TYPE=name) Moura, A.M.C”>
42
<META NAME=“package”
CONTENT=“(TYPE=end) Dublin Core”>
</HEAD>
3.2.1.1- Relacionamentos Ativos Distribuídos (DARs)
DARs
(Distributed
Active
Relationships)
(LAGOZE
&
DANIEL,
1997),
Relacionamentos Ativos Distribuídos, é uma extensão da Arquitetura Warwick. É uma
arquitetura, porém foi denominada modelo para representação de dados e metadados.
Expressa os relacionamentos entre recursos de rede, e permite que os relacionamentos sejam
dinamicamente recuperáveis e executáveis. O modelo DAR é baseado nos seguintes
princípios:
• Não existe distinção essencial entre dado e metadado; o que é metadado em um contexto
pode ser dado em outro;
• Recursos podem ser relacionados sem se considerar suas localizações;
• Dado sobre um outro conjunto de dados pode não existir fisicamente, mas pode ser
derivado automaticamente. O relacionamento pode ser um objeto executável, no sentido de
metadado interpretável.
Assim, no modelo DAR pacotes de metadados podem ser virtuais e o dado do pacote
pode existir como resultado da computação em algum outro recurso. O metadado retornado ao
cliente pode ser um objeto executável, ou um manipulador para um objeto usando tecnologia
de objetos distribuídos tal como CORBA.
Nesse modelo, relacionamentos também são dados, sendo identificados e recuperados
como qualquer outro recurso.
A Figura 3.2 mostra um modelo DAR que gerencia os direitos de acesso a um recurso,
baseado em uma lista de controle de acesso. O Pacote de Ativação significa um componente
43
executável do relacionamento que é invocado quando o cliente acessa o conteúdo no Pacote
P1. O Pacote de Descrição no recipiente de relacionamento pode ser alguma descrição textual
do relacionamento. O objeto relação é um objeto digital referenciado através de um
identificador global URN1 no catálogo de relacionamento.
FIGURA 3.2: Exemplo de uso do DARs para gerenciamento de direitos.
3.2.2- Arquitetura de Descrição de Conteúdo (MCF)
A MCF (Meta Content Framework), arquitetura de descrição de conteúdo, constitui-se
basicamente de uma linguagem de descrição de estrutura baseada em um modelo de dados
extensível apresentado pelo Netscape para o consórcio World Wide Web (GUHA & BRAY,
1997).
Por meio da MCF cada aplicação pode adicionar e usar seus próprios tipos de
metadados. O modelo de dados MCF inclui um conjunto de tipos básicos que podem ser
estendidos para acomodar novos tipos de dados. MCF define também um vocabulário básico
que inclui um conjunto de termos comuns usados para descrever o conteúdo de documentos
Web.
Um banco de dados MCF é um conjunto de DLGs (Directed Linked Graph)
compreendendo: um conjunto de etiquetas (referidas como propriedades); um conjunto de
44
nós; um conjunto de arcos, onde cada arco é uma tripla consistindo de dois nós (origem e
destino) e uma etiqueta.
Na MCF os nós podem representar coisas como páginas Web, imagens, categorias de
assuntos, e sites. Podem também representar objetos do mundo real tais como pessoas, lugares
e eventos. Etiquetas são nós que correspondem a propriedades tais como tamanho ou data da
última revisão para descrever páginas web e relações (tal como hiperlinks). Cada
propriedade/etiqueta representa um nó, porém nem todos os nós são propriedades.
A Figura 3.3 apresenta um quadro DLG representando dados MCF. Domain é um tipo
de propriedade, e cada ocorrência desse como etiqueta indicada pela seta é uma propriedade.
As setas são somente ponteiros de algum tipo, e os objetos são estruturas na memória ou
objetos em uma tabela de banco de dados.
FIGURA 3.3: Quadro DLG representando dados MCF.
MCF é representada através de uma sintaxe baseada na XML (Extensible Markup
Language), a qual conserva as vantagens de extensibilidade da SGML (Standard Generalized
Markup Language), considerada como uma linguagem de representação de dados de
propósito geral extensível. Os hiperlinks XML são usados para referenciarem os blocos MCF
armazenados externamente. Esses são importantes pois permitem o compartilhamento e reuso
de descrições, evitando duplicação.
45
3.2.3- Arquitetura de Descrição de Recurso (RDF)
A RDF (Resource Description Framework), arquitetura de descrição de recurso,
especificada pela W3C
(World Wide Web Consortium), provê interoperabilidade entre
aplicações que trocam informações através da Web (LASSILA & SWICK, 1997). RDF
enfatiza facilidades para disponibilizar processamento automático de recursos na Web, com o
objetivo de definir um mecanismo para descrever recursos de informação sobre qualquer
domínio.
Metadado no contexto da RDF significa “dado descrevendo recursos Web”. RDF
utiliza XML (Extensible Markup Language) como sintaxe de codificação para os metadados.
Os recursos descritos pela RDF podem geralmente ser nomeados por um URI (Universal
Resource Identifier).
O núcleo do modelo de dados é definido como: um conjunto de nós, chamado de N;
um subconjunto de N conhecido como os tipos de propriedades, chamados P; um conjunto de
triplas T, cujos elementos são informalmente conhecidos como propriedades, sendo que o
primeiro item de cada tripla é um elemento de P, o segundo item é um elemento de N e o
terceiro item é um elemento de N ou um valor atômico.
Modelos RDF são grafos direcionados rotulados, onde nós representam recursos Web,
e arcos estabelecem propriedades (“Autor”, por exemplo) associadas a um nó. Estas
propriedades servem para representar atributos dos recursos e relacionamentos entre eles.
Tanto os recursos sendo descritos quanto os valores que os descrevem são nós. Os arcos
conectando pares de nós correspondem aos nomes dos tipos de propriedades.
A Figura 3.4 mostra exemplos usando RDF (LASSILA & SWICK, 1997), onde os
círculos são recursos que estão sendo descritos e os retângulos os respectivos valores
dependendo da propriedade indicada na linha de ligação.
46
FIGURA 3.4: Exemplos RDF.
E os exemplos da Figura 3.4 podem ser substituídos pela representação de serialização XML:
3.2.4- Arquitetura Segundo Chang e Zhang
Na arquitetura de metadados proposta por (CHANG & ZHANG, 1997) para tratar
metadados em banco de dados visual, apresentada na Figura 3.5, o metaservidor consiste de
quatro componentes: coletor de metadados, meta-banco de dados, construtor de template e
módulo de refinamento de metadados. Esta é uma arquitetura diferente das apresentadas
47
anteriormente, pois é uma arquitetura operacional, que preocupa-se apenas em descrever as
funcionalidades existentes de forma a permitir trabalhar com os metadados.
O papel do metaservidor é aceitar consultas de usuário, transformar a informação da
consulta para um índice de metadado adequado, distribuir as consultas para os bancos de
dados selecionados e retransmitir suas respostas de volta aos usuários.
Imagens no banco de dados visual podem ser categorizadas com base em similaridade
com relação a um conjunto de imagens, gerando templates.
FIGURA 3.5: Arquitetura de Metadados
O coletor de metadados coleta os metadados do banco de dados de imagem. O banco
de dados então computa as similaridades de suas imagens com todos os templates. O coletor
de metadados então armazena os metadados no meta-banco de dados. Os bancos de dados
registrados no metaservidor ao serem atualizados permitem que os seus metadados sejam
dinamicamente atualizados. O módulo de refinamento inicia periodicamente as atualizações
dos metadados pedindo aos bancos de dados para resubmeterem os metadados ao coletor.
Ao receber uma consulta o metaservidor primeiro extrai várias classes de
características da consulta. A consulta então é decomposta em sub-consultas, cada uma
representando uma classe de características a ser recuperada do banco de dados de imagens.
Depois o mecanismo de busca do metaservidor casa cada sub-consulta com os templates mais
relacionados. As similaridades entre a sub-consulta e o template são então indexadas com a
48
informação estatística correspondente aos bancos de dados para derivar a lista dos bancos de
dados relacionados à sub-consulta. E, finalmente, as listas dos bancos de dados para as subconsultas são agrupadas para produzirem o conjunto final de bancos de dados para a dada
consulta.
3.3- ARQUITETURA DE MODELAGEM SEGUNDO KERHERVÉ
Nas seções anteriores foram mostradas arquiteturas para tratamento de metadados,
tendo cada uma um enfoque específico para o tratamento da informação. Nesta seção será
apresentada uma arquitetura mais genérica proposta por (KERHERVÉ, 1997) apresentando
um formalismo que permite uma representação homogênea dos diferentes níveis de
modelagem.
FIGURA 3.6: Arquitetura de modelagem segundo Kerhervé.
A Figura 3.6 apresenta uma arquitetura de modelagem de quatro níveis que permite a
representação de metadados a partir da estrutura dos elementos de dados. Os diferentes níveis
de modelagem permitem também incorporar modelos e metamodelos para metadados.
•
Nível de dado corresponde às instâncias que são manipuladas no sistema. O tipo de
metadado que pode ser extraído refere-se aos aspectos físicos e de conteúdo dos dados;
•
Nível de descrição do modelo de dados é o conceito usado para descrever dados e
metadados. O metadado referente à estrutura pode ser extraído. Nesse nível pode ser
49
encontrado também o modelo para metadados, que é o esquema de metadados ou estrutura
dos elementos de metadados;
•
Nível de meta-modelo define o formalismo do modelo que é usado no sistema. Descreve
os conceitos usados para representar a informação nos níveis mais baixos. Tais metadados
são usados para interoperabilidade de ferramentas, métodos ou sistemas.
•
Nível de meta-meta modelo é a raiz do nível de modelagem permitindo uma representação
homogênea dos outros níveis e uma interoperação mais fácil entre os modelos dos níveis
mais baixos.
Nesta arquitetura foram escolhidos grafos conceituais pelo poder de expressão e a
possibilidade de manipular tipos e instâncias. Grafo conceitual é um formalismo pelo qual um
universo de objetos podem ser modelados por conceitos e relações conceituais. Um conceito
representa um objeto de interesse ou conhecimento. Uma relação conceitual torna possível
associar esses conceitos.
3.4- SISTEMAS UTILIZANDO METADADOS PARA IMAGEM
•
Sistema VisualHarness
O Sistema VisualHarness (SHAH et alii., 1997) usa componentes da plataforma do
Sistema InfoHarness (SHKLAR et alii., 1994) que suporta dados textuais e faz extensões para
utilizar dados visuais, utilizando dados de imagem. A arquitetura do sistema VisualHarness é
aberta e extensível e permite ser usada por mecanismos de indexação para dados textuais e
mecanismos VIR (Visual Information Retrieval) para acesso baseado no conteúdo da imagem.
VisualHarness usa um sistema de gerenciamento de banco de dados relacional.
O VisualHarness utiliza um componente de acesso baseado em imagem chamado
IBAC (Image Based Access Component), que suporta recuperação de imagem por conteúdo
50
usando BBA (black-box approach), abordagem de caixa-preta proposta por (SHAH et alii.,
1997). O objetivo da BBA é usar representações de características sem conhecer o interior do
mecanismo VIR (Visual Information Retrieval) ou o formato a partir do qual as características
são geradas, armazenadas ou manipuladas pelo mecanismo.
As propriedades da imagem são tratadas como metadados dentro do sistema
VisualHarness. Todos os valores de metadados, isto é, suas características, são précomputadas e armazenadas no banco de dados de metadados. O banco de dados de metadados
possui índices (como por exemplo: índices de texto para dados textuais e índice baseado na
forma para dados imagem) além de atributos baseados em metadados e futuramente extratores
de metadados em tempo de execução. Dados sobre os relacionamentos entre objetos são
criados e armazenados junto com os próprios metadados.
IBAC é responsável por normalizar e escalar a saída de acordo com os pesos
associados a cada propriedade da imagem. Os pesos atribuídos pelo usuário auxiliam na
recuperação por similaridade.
•
DISIMA (DIStributed Image database MAnagement system)
O projeto DISIMA (ORIA et alii, 1997), Sistema de Gerenciamento de Banco de
Dados de Imagem
Distribuído, tem o objetivo de possibilitar consultas baseadas em
conteúdo. Um protótipo está sendo implementado no SGBDOO ObjectStore.
O modelo especificado pelo DISIMA endereça banco de dados de imagem e espacial.
Apresenta similaridades com o modelo VIMSYS (seção 2.4.2.3) pela visão dos dados da
imagem em multi-níveis. Os objetos dentro da imagem são denominados objetos salientes,
isto é, identificados na imagem.
O modelo DISIMA é composto de dois blocos principais: o bloco imagem e o bloco
objeto saliente. O bloco imagem é constituído de dois níveis: o nível imagem e o nível de
51
representação da imagem. O nível imagem permite ao usuário definir uma classificação de
tipo de imagem similar aos sistemas de tipo de objeto, existindo dois modos de representação
para o nível de representação da imagem: o rastreado e o vetorizado.
O bloco objeto saliente é a forma do DISIMA visualizar o conteúdo de uma imagem
com relacionamentos espaciais. Existem dois tipos de objetos salientes: - objeto saliente
lógico é uma abstração de um objeto saliente relevante a alguma aplicação; é um objeto usado
para dar semântica a um objeto saliente físico; - objeto saliente físico refere-se à imagem i; é
parte de uma imagem caracterizada por uma posição (conjunto de coordenadas) no espaço da
imagem. Propriedades adicionais como cor, textura e forma podem ser definidas para um
objeto saliente físico.
O reconhecimento de objeto saliente combina interpretação automática e manual das
imagens. A interpretação automática pode processar vários algoritmos de reconhecimento de
padrões e análise das imagens para capturar o conteúdo de uma imagem.
DISIMA provê uma arquitetura interoperável utilizando as facilidades da arquitetura
CORBA, permitindo aos usuários consultarem a fontes múltiplas de imagem e possivelmente
remotas.
O
ambiente
completamente
distribuído
provido
pela
Internet
requer
a
interoperabilidade entre padrões e implementações existentes, requisitos importantes para a
extensibilidade e adaptação de modelos e metamodelos.
Os padrões e arquiteturas de metadados estudados devem ser considerados quando se
pensa na utilização de metadados. Dentre os inúmeros padrões estudados, apenas o DC e o
SAIF foram considerados, por darem alguma conotação a dado multimídia. Porém, ambos
52
não são totalmente adequados à descrição mais eficiente de imagens, pois não viabilizam
descritores para todas as suas características importantes.
Dentro das arquiteturas de metadados estudadas pode ser visto que todas se
preocupam com a extensibilidade de seus modelos e com a possibilidade de utilização em
domínios diferentes. A arquitetura Warwick utiliza o conceito de pacote como uma forma de
extensibilidade, aceitando com isso metadados de padrões variados. O modelo DARs provê a
representação de relacionamentos entre recursos de rede, permitindo ainda que os
relacionamentos sejam dinamicamente recuperáveis e executáveis.
As arquiteturas MCF e a RDF usam uma sintaxe baseada em XML e possibilitam a
utilização de metadados em geral, visando a utilização na Web, enquanto que a arquitetura
segundo Chang e Zhang permite um tratamento especial de metadados para bancos de dados
visuais, dando ênfase à parte operacional do tratamento dos metadados.
Os sistemas estudados que utilizam metadados para imagem não se preocupam em
definir todas as características da imagem. Pensando no uso de um banco de dados de imagem
na prática, o que realmente interessa é a possibilidade de efetuar consultas baseadas em
informações referentes ao conteúdo semântico da imagem e não somente características como
cor, textura e formas predominantes. Existem algumas formas, embora limitadas, de utilizar
metadados para imagem, porém não foi encontrada de forma explícita uma especificação
sistemática e mais completa dos elementos descritores ou de suas classificações.
O objetivo desse trabalho vai ao encontro à necessidade de se criar um esquema
conceitual de metadados para imagem, considerando seu uso para a descrição de um banco de
dados de imagem.
O próximo capítulo irá apresentar a especificação de um esquema conceitual de
metadados para imagem que possibilitará a descrição e recuperação de imagens em bancos de
53
dados de imagem, levando em consideração informações técnicas e informações de conteúdo
semântico.
54
CAPÍTULO 4
MODELAGEM CONCEITUAL DE METADADOS PARA IMAGEM
O esquema aqui apresentado vem complementar as abordagens (Recuperação da
Inteligência Artificial Aplicadas à Recuperação de Imagem) tratadas no Capítulo 2 e os
padrões de metadados considerados no Capítulo 3. As abordagens utilizam estratégias
diferenciadas para conseguirem efetuar consultas às imagens, mas não se preocupam com
uma descrição mais completa das características das imagens. Os padrões considerados no
Capítulo 3 foram apenas o DC e o SAIF, por darem alguma conotação a dado multimídia.
Porém ambos não são totalmente adequados à descrição mais eficiente de imagem, pois não
viabilizam descritores para todas as suas características importantes.
Este esquema viabiliza uma representação sistemática e detalhada dos elementos
descritores de imagens estáticas digitais, incluindo tanto elementos para descrever as
informações técnicas da imagem quanto para descrever as informações de conteúdo
semântico, podendo com isso ser utilizado em arquiteturas de metadados existentes.
Além dos estudos das diferentes abordagens que tratam a imagem na área de Ciência
da Computação, foram também pesquisadas as formas de descrição de imagens na área de
Ciência da Informação, já que a catalogação e indexação de imagem também é objeto de
estudo desta área.
Quem lida com imagem sabe que esta requer que sejam descritas as suas informações,
principalmente as menos evidentes: o que caracteriza um “sorriso meio triste”? E “cabelos
meio ralos”? Como descrever e, sobretudo, analisar imagens para fins de catalogação? Como
dar conta deste tipo de material? Com exemplos desta ordem, cabe até questionar se é
55
possível “analisar” as informações relacionadas ao conteúdo semântico das imagens (SMIT,
1987). A partir desses questionamentos ocorre uma 1a divisão entre as opiniões:
-
considera-se que a análise da imagem não tem nada de específico e que as boas e
comprovadas técnicas da análise documentária resolvem perfeitamentes a questão;
ou
-
parte-se do princípio de que as técnicas de análise de documentos escritos não são
apropriados para analisar imagens.
É problemática a distinção entre o que seja descrição e interpretação, uma vez que a
descrição da imagem, pela operação de tradução do código icônico para o código verbal, cria
condições para sua interpretação. A grande dificuldade na análise da imagem consiste nesta
separação entre a denotação (o que a imagem mostra) e a conotação (o que a sociedade e o
bibliotecário vêm na imagem). Por exemplo: não existem imagens de “agricultura” ou de
“racismo”. O que existe são plantações de soja ou milho, ou cartazes em cima de portas com
dizeres do tipo “for white only”.
4.1- VISÃO SEGUNDO A CIÊNCIA DA INFORMAÇÃO
A questão da representação das imagens em Ciência da Informação é analisada
também por Erwin Panofsky em 1979 (PANOFSKY, 1979), estabelecendo níveis para a
análise da imagem que ajudam a nortear a questão. Esse autor detalha três níveis para a
análise da imagem:
Pré-iconográfico: são descritos, genericamente, os objetos e ações representados
pela imagem;
Iconográfico: estabelece o assunto secundário ou convencional ilustrado pela
imagem. Trata-se da determinação do significado abstrato ou simbólico da
56
imagem, sintetizado a partir de seus elementos componentes, detectados pela
análise pré-iconográfica;
Iconológico: propõe uma interpretação do significado intrínseco do conteúdo da
imagem. A análise iconológica constrói-se a partir das anteriores, mas recebe
fortes influências do conhecimento do analista sobre o ambiente cultural, artístico
e social no qual a imagem foi gerada.
Panofsky exemplifica os diferentes níveis de análise a partir de uma imagem simples,
como por exemplo, um homem segurando o chapéu levantado acima da cabeça (SMIT, 1996).
Ao nível pré-iconográfico, a análise ressalta a existência do homem e seu gesto (erguer o
chapéu), sendo que, ao nível iconográfico, a mesma imagem seria analisada enquanto
representativa de um ato de cortesia. A análise iconológica, por sua vez, contextualizaria o ato
de cortesia na realidade social e cultural do local e da época em que a imagem foi gerada,
construindo, a partir desses dados, uma proposta de código de cortesia em certa classe social e
dado momento histórico.
A imagem é, simultaneamente, específica e genérica (SHATFORD, 1986): a imagem
de uma ponte, por exemplo, representa tanto a categoria genérica (nível pré-iconográfico) das
pontes como também uma ponte em particular (nível iconográfico), por exemplo a Ponte das
Bandeiras, em São Paulo. Entretanto, o usuário só pode formular suas necessidades
informacionais em termos do que ele já conhece. Resgatando a terminologia de Panofsky: se
um usuário só entende o sentido pré-iconográfico de uma imagem (por exemplo: ponte), ele
não pode formular suas necessidades em termos iconográficos (por exemplo: Ponte das
Bandeiras).
A análise de Panofsky e as categorias Quem (seres), Onde (espaço), Quando (tempo),
Como (técnica) e O que (ação), utilizadas por muitos estudiosos como parâmetros para grande
variedade de análises de textos, também são utilizadas para a análise documentária da
57
imagem. Shatford retoma as mesmas categorias para a representação da imagem, introduzindo
uma distinção entre De genérico, De específico e Sobre, como pode ser visto na Tabela 4.1. E
por meio destas categorias pode ser amenizada a problemática, dita anteriormente, da
denotação (o que a imagem mostra) e conotação (o que a sociedade e o bibliotecário vêm na
imagem).
Pode ser concluído que não existe uma padronização para a descrição de imagens
estáticas de forma genérica, pois os pesquisadores da área de Ciência da Informação
trabalham de acordo com o acervo a ser descrito, não existindo uma categorização formal que
sirva para a descrição de qualquer imagem. O padrão criado por (SHATFORD, 1986) para
descrição de documentos em geral pode ser utilizado também para descrever imagens e esse
padrão foi utilizado por (SMIT, 1996) para a representação da imagem. Como exemplo de
descrição de imagem baseada em acervo pode ser citado o trabalho de (CORDEIRO, 1990) no
qual é criada uma planilha contendo elementos de identificação e representação visando
indexação e recuperação das informações contidas em fotografias de cenas e fotogramas de
filmes. Grande parte das categorias e formas de representação de conteúdo da imagem
estudadas em (SMIT, 1996) e (CORDEIRO, 1990) foram de certa forma acopladas à
especificação do esquema proposto por esse trabalho. Uma outra fonte de pesquisa utilizada
foi o Manual Para Catalogação de Documentos Fotográficos (FUNARTE, 1998), que trouxe
idéias de como na prática os profissionais fazem a catalogação de fotos, contribuindo também
para a especificação do esquema proposto.
Os metadados podem ser definidos em nível de pixel, nível semântico e nível de
domínio (informações específicas de uma determinada aplicação). Os metadados escolhidos
para caracterizarem uma dada imagem podem então ser modelados através do Esquema
Conceitual de Metadados para Imagem proposto e descrito ao longo deste capítulo.
58
Categoria
Definição geral
QUEM
Animado
e Esta imagem é de De
quem,
inanimado,
quem? De Que especificamente,
objetos e seres objetos? De que se trata?
concretos.
seres?
Exemplo
ONDE
QUANDO
O QUE
DE genérico
Ponte
DE específico
Ponte
Bandeiras
SOBRE
Os
seres
ou
objetos
funcionam como
símbolos
de
outros seres ou
objetos?
Representam a
manifestação de
uma abstração?
das Urbanização
Onde está a Tipos de lugares
imagem
no geográficos,
espaço?
arquitetônicos ou
cosmográficos
Nome de lugares
geográficos,
arquitetônicos ou
cosmográficos
O
lugar
simboliza
um
lugar diferente ou
mítico? O lugar
representa
a
manifestação de
um pensamento
abstrato?
Exemplo
Amazonas
Paraíso
(supõe
um contexto que
permita
esta
interpretação)
Tempo linear ou Tempo cíclico
cíclico, datas e
períodos
específicos,
tempos
recorrentes.
Tempo linear
Raramente
utilizado,
representa
o
tempo
a
manifestação de
uma
idéia
abstrata
ou
símbolo?
Exemplo
1996
Esperança,
fertilidade
O que os objetos Ações, eventos
e seres estão
fazendo? Ações,
eventos,
emoções
Eventos
individualmente
nomeados
Que
idéias
abstratas
(ou
emoções) estas
ações
podem
simbolizar?
Exemplo
Copa do Mundo
Esporte
Selva
Verão
Jogo de futebol
TABELA 4.1: Categorias para a representação da imagem (SHATFORD, 1986).
59
4.2- CARACTERÍSTICAS
O Esquema Conceitual de Metadados para Documentação e Recuperação de Imagens
apresentado na Figura 4.1, tem como objetivo principal suportar as seguintes características:
simplicidade e adaptabilidade a qualquer domínio de aplicação. Este esquema possui classes
as quais contêm propriedades referentes às características da imagem.
Nesta proposta, considerando um Objeto Imagem, sabe-se que podem existir versões
diferentes para um mesmo objeto, estas versões também são Objetos Imagem. Os objetos
imagem podem ainda estar associados a outros objetos imagem, como por exemplo: um
objeto imagem pode ser composto de outros objetos imagens, pode ser parte de um outro
objeto imagem ou ter sido derivado de outro objeto imagem. Com relação às classes de
descritores para o objeto imagem, foram identificadas três classes principais: Objeto Imagem,
Conteúdo Semântico e Tipo de Relacionamento (existente entre os componentes da imagem).
Cada uma dessas classes associa uma gama de informações com objetivos específicos, a
saber:
• Objeto Imagem: representa em sua maioria um conjunto de propriedades
consideradas informações técnicas relativas ao objeto imagem (imagem digitalizada);
• Conteúdo Semântico: representa o conjunto de categorias que descrevem o conteúdo
semântico do objeto imagem, possibilitando identificar os componentes existentes na
imagem; o conceito de categoria foi adquirido por meio dos estudos da Ciência da
Informação com (SMIT, 1996) (SHATFORD, 1986) (CORDEIRO, 1990);
• Tipo de Relacionamento: representa o tipo de relacionamento existente entre os
componentes da imagem, aspecto importante e necessário para melhor descrever o
contexto da informação.
60
Além das características do Objeto Imagem também é importante especificar as
características da Imagem Original, a partir da qual foi gerada a imagem digital (Objeto
Imagem). A importância da especificação da imagem original foi identificada a partir da
consulta aos trabalhos de catalogação de fotografias realizados na FUNARTE. E além das
categorias (O Que (Ação), Onde (Espaço), Quando (Tempo), Quem (Componente)) de
Shatford, foi identificada ainda junto aos trabalhos práticos de descrição de imagens, como
por exemplo (GEMINI, 1998), a necessidade de ser disponibilizada mais uma categoria para
descrever o conteúdo semântico, que no caso recebe neste modelo a denominação Finalidade
(Para Que), possibilitando especificar o objetivo de utilização ou armazenamento daquela
imagem digital.
A seção seguinte mostra a especificação das classes existentes no esquema proposto
de forma mais detalhada.
4.3- ESPECIFICAÇÃO DE CLASSES
O esquema proposto pode ser visualizado através da Figura 4.1, utilizando a
linguagem de modelagem de objetos - UML (Unified Modeling Language) (FURLAN, 1998).
Na Tabela 4.2 é apresentada a legenda utilizada para a representação da estrutura de classes
segundo a notação UML. A descrição das classes e suas propriedades são vistas a seguir:
61
FIGURA 4.1: Esquema Conceitual de Metadados para Imagem.
62
TABELA 4.2: Legenda utilizada na representação da estrutura de classes do esquema.
Este esquema conceitual viabiliza a documentação de imagem estática do tipo
fotografia, pintura ou gravura qualquer descrevendo suas propriedades, possibilitando também
descrever os componentes contidos na imagem e os relacionamentos existentes entre eles. O
esquema permite também identificar os objetos imagem que são versões de um objeto
imagem e os tipos de associações existentes entre os mesmos.
Vale a pena ressaltar algumas observações sobre o conceito de versão, representado
pelo auto-relacionamento possui versão, adotado neste esquema. Um objeto imagem só será
considerado versão de outro se o seu conteúdo semântico não tiver sido alterado, isto é, se
parte da imagem não tiver sofrido nenhuma modificação. Sendo assim, não será necessário
efetuar a descrição referente à classe conteúdo semântico daquele objeto imagem que tiver
sido versionado de outro. As informações de conteúdo semântico da versão poderão ser
obtidas por meio do objeto de onde foi versionado. No caso de versões que sofreram alteração
em relação a cor e que perderam algumas características do seu conteúdo semântico, será
possível descrever um novo conteúdo semântico para a versão. Considere, por exemplo, uma
imagem colorida que contenha o por do sol. Ao ser versionada para uma imagem em preto e
branco provavelmente não mais será possível perceber o por do sol. Neste caso, uma nova
descrição para a versão deverá ser efetuada, de forma a representar esse novo conteúdo
semântico.
63
O auto-relacionamento associado a é utilizado para representar a situação em que uma
imagem foi modificada. Considere, por exemplo, uma imagem que foi gerada a partir de um
pedaço de outra imagem. A nova imagem gerada possuirá conteúdo semântico diferente da
imagem da qual foi gerada. Neste caso, o relacionamento existente entre as duas imagens será
representado por meio do relacionamento associado a e os tipos de associações serão
denominados parte de para a imagem que foi gerada a partir da outra e composto de para a
imagem que possui em sua composição a imagem gerada.
A seguir será apresentada uma descrição detalhada de cada uma das classes existentes
no esquema.
4.3.1- Objeto Imagem
Um Objeto Imagem representa a imagem digitalizada descrita pelo esquema. As
propriedades contidas nessa classe representam um conjunto de características da imagem
digital que são consideradas informações técnicas. Por meio do auto-relacionamento possui
versão podem ser obtidos os objetos imagem que são versões de outro objeto imagem. E o
auto-relacionamento associado a representa qual o tipo de associação entre os objetos
imagem, caso exista. O Objeto Imagem é representado pelas seguintes propriedades
(atributos):
-
Título: nomeação dada a imagem digital para facilitar a sua identificação;
-
Fonte: local de origem da imagem digital; informação sobre a fonte individual,
agência ou do repositório de onde a imagem foi obtida;
-
Formato: formato do arquivo da imagem (como por exemplo: JPEG, GIF, PNG,
SPIFF, etc);
64
-
Esquema de compressão: tipo de compressão utilizado na criação da imagem digital;
como por exemplo: JBIG, LZW, etc;
-
Dimensão do arquivo: tamanho do arquivo em bytes;
-
Dimensão da imagem digital: tamanho da imagem em pixels, polegadas, centímetros
e/ou milímetros; campo composto contendo o valor e o tipo de unidade utilizada para
a descrição da dimensão da imagem digital;
-
Resolução: número de unidades do tipo de medida (pixels/bits/etc) utilizadas na
descrição da resolução da imagem digital;
-
Localização física: local onde a imagem encontra-se fisicamente armazenada; pode
ser um diretório em uma rede ou uma URL;
-
Dispositivo de armazenamento: dispositivo físico onde a imagem está armazenada;
-
Lugar do repositório: localização geográfica do repositório;
-
Direitos autorais: nome ou identificação do autor ou autores da imagem digital, no
caso da imagem não possuir foto original, isto é, se ela tiver sido criada diretamente
na forma digital;
-
Proprietário: nome ou identificação do proprietário da imagem digital;
-
Digitalizador: nome ou identificação da pessoa que digitalizou, no caso de não ter
sido criada diretamente na forma digital;
-
Tipo de digitalizador: aparelho utilizado para criação da imagem digitalizada;
-
Data da criação: data associada à criação ou produção da imagem digital;
-
Software usado para criação: software usado na criação da imagem digital;
-
Espaço de cor: tipo padrão de cores usadas (por exemplo: RGB (Red, Green, Blue),
HSV (Hue, Saturation, Value), CMYK (Cyan, Magenta, Yellow, Black), etc);
-
Cromia: cromia da imagem digital, por exemplo: preto e branco, colorida;
65
-
Histograma de cor: distribuição das cores existentes na imagem digital em cada pixel.
Suponha que a imagem tenha N cores; a idéia é responder a “quantos pixels a cor X
tem associados?”, isto é, contar os pixels referentes a uma dada cor. O histograma de
cor é representado por meio de um vetor gerado automaticamente por um algoritmo
(CAETANO et alii, 1998);
-
Textura: segundo (MEYER, 1997) não existe uma definição simples e sem
ambiguidades e a razão para isso é o conceito fortemente intuitivo de textura,
impossível de ser totalmente descrito em uma definição textual. A textura é
representada por meio de um vetor gerado automaticamente por um algoritmo, como
por exemplo os algoritmos conhecidos como atributos CCD (Contrast, Coarseness e
Directionality) de Tamura, transformada de Wold, Modelo SAR (Simultaneous AutoRegressive), RISAR (Rotation-Invariant SAR), MRSAR (Multi-Resolution SAR),
GLCM (Grey Level Co-ocurrence Matrix) e GMRF (Gaussian Markov Random
Field) (CAETANO et alii, 1998);
-
Brilho: proporcional à integral do produto da curva e à função de eficiência de
luminosidade, esse cálculo é feito automaticamente por meio de um algoritmo
gerando um vetor (FOLEY et alii, 1990).
4.3.2- Imagem Original
A classe Imagem Original contém informações sobre a imagem original (fotografia,
pintura, gravura, etc) que passou por processo de digitalização gerando assim o Objeto
Imagem; está sendo representada pelas propriedades (atributos) (FUNARTE, 1998):
-
Gênero: descrição genérica da imagem original, como por exemplo: fotografia, slide,
pintura, gravura, etc;
66
-
Processo: no caso da fotografia representa a designação específica, isto é, o tipo de
processo fotográfico utilizado na produção da foto, como por exemplo:
daguerreotipia, ambrotipia, gelatina, platinotipia, etc; com relação aos outros gêneros
(pintura, gravura, etc) de imagem original também poderá ser descrito o respectivo
processo;
-
Cromia: cromia da imagem, tal como por exemplo: preto e branco, colorida;
-
Dimensões: dimensões da imagem original;
-
Dimensões primárias: dimensões do suporte primário (papel fotográfico) onde está a
imagem;
-
Dimensões secundárias: dimensões do suporte secundário (moldura) onde está a
imagem;
-
Suporte primário: tipo de suporte primário onde está a foto, os tipos de suporte podem
ser: papel, couro, porcelana, tecido, madeira;
-
Características técnicas adicionais: características técnicas adicionais utilizadas no
processo de produção da imagem original, como por exemplo no caso de fotografia as
características podem ser: solarizada, foto montagem, etc;
-
Nome da coleção: no caso da imagem original pertencer a alguma coleção;
-
Número de exemplares: número de exemplares daquela imagem original existente no
acervo;
-
Nota: indicação da página ou número correspondente para acesso, como por exemplo
no caso de uma foto integrar um álbum;
-
Direitos autorais: nome ou identificação do autor ou autores da imagem original;
-
Proprietário: nome ou identificação do proprietário da imagem original;
-
Repositório: local onde se encontra a imagem original.
67
4.3.3- Tipo de Associação
O Tipo de Associação representa a associação existente entre os objetos imagem, de
acordo com o campo:
-
Tipo: tipo de associação existente entre objetos imagem. Pode assumir os seguintes
valores: composto de, parte de, derivado de. Aqui pode ser representado se um objeto
imagem é composto de outros objetos imagem, se ele é parte de um outro objeto
imagem ou se ele foi derivado de outro objeto imagem.
4.3.4- Conteúdo Semântico
A classe Conteúdo Semântico representa informações referentes ao conteúdo
semântico da imagem, contendo a descrição das categorias
(Ação (O Que), Espaço (Onde), Tempo (Quando), Componente (Quem))
de acordo com (SHATFORD, 1986), acrescentando-se uma outra categoria denominada
Finalidade (Para Que). Essa classe contém as seguintes propriedades:
-
Nome: nome da categoria que estará sendo descrita; que poderá ser: Ação, Espaço,
Tempo, Componente ou Finalidade;
Essas categorias (Nome) são melhor explicadas a seguir:
•
Ação: o que os objetos e seres estão fazendo (ações, eventos, emoções);
•
Espaço: onde está a imagem no espaço;
•
Tempo: tempo linear ou cíclico, datas e períodos específicos, tempos
recorrentes;
68
•
Componente: esta categoria é transformada em classe já que possui
relacionamentos com outras classes e esses relacionamentos só existem no caso
do nome da categoria ser Componente, descrita em 4.3.4.1;
•
Finalidade: objetivo de utilização ou armazenamento daquela imagem digital,
para que a imagem está sendo armazenada; como por exemplo: “imagem a ser
utilizada no cenário de uma determinada novela”;
-
Descrição genérica: descrição genérica daquela categoria de conteúdo semântico;
-
Descrição específica: descrição específica daquela categoria de conteúdo semântico;
(De Quem, de Onde, de Quando, do Que e Para Que especificamente se trata a
imagem?)
-
Sobre: sobre qual assunto a imagem trata de acordo com a categoria (Nome) que está
sendo descrita; (representa a manifestação de alguma abstração?).
Exemplos de descrições utilizando a classe Conteúdo Semântico:
Nome = Ação
Nome = Espaço
Nome = Tempo
Descrição genérica = jogo de Descrição genérica = Perfil Descrição
futebol
da cidade
Primavera
genérica
=
Descrição específica = Copa Descrição específica = Rio Descrição específica = 1998
do Mundo 1998
de Janeiro
Sobre =juventude, esperança
Sobre = Esporte
Sobre = Cidade maravilhosa
4.3.4.1- Componente
A classe Componente identifica os componentes da imagem. Podem ser animados e
inanimados, objetos e seres concretos. Componente é uma categoria da classe conteúdo
semântico que foi tranformada em uma classe porque possui relacionamentos com outras
69
classes, conforme pode ser observado no Esquema especificado por meio da Figura 4.1. A
tabela a seguir mostra exemplos de descrições utilizando a classe Componente:
Nome = Componente
Descrição genérica = Menina
Descrição específica = Simone
Sobre = Infância
Nome = Componente
Descrição genérica = Ponte
Descrição específica = Ponte das Bandeiras
Sobre = Urbanização
4.3.5- Tipo de Relacionamento
Esta classe representa o tipo de relacionamento existente entre os componentes da
imagem. Todos os tipos de relacionamentos identificados nesta classe servem para indicar
como um componente está espacialmente localizado em relação a outro ou outros dentro de
uma imagem. Esse tipo de relacionamento é representado por meio do seguinte campo:
-
Posição: em que posição um determinado componente está em relação a outro ou a
outros. Pode assumir os seguintes valores: lado direito, lado esquerdo, frente, atrás,
abaixo, acima, sobreposto, diagonal frente direita, diagonal frente esquerda, diagonal
atrás direita, diagonal atrás esquerda, centro, etc.
4.3.6- Representação Posicional
A Representação Posicional identifica em que posição está o componente da imagem
que pertence a classe Componente, por meio dos seguintes campos (CORDEIRO, 1990):
-
Ângulo: em que ângulo está o componente; por exemplo: frente, perfil, costas, etc;
-
Posição: em qual posição está o componente; por exemplo: agachado, caído, de
cabeça para baixo, ajoelhado, vertical, horizontal, etc;
70
-
Disposição: disposição do componente na imagem, como por exemplo: corpo inteiro,
não corpo inteiro, mãos, pernas, cabeça até o busto, cabeça até o joelho.
4.3.7- Representação Factual
A Representação Factual identifica o tipo de classificação do componente da imagem
pertencente a classe Componente, sendo esta classificação dos tipos Ser, Reino, Força da
Natureza e Objeto segundo (CORDEIRO, 1990). Esses tipos são sub-classes da classe
representação factual, descritas a seguir.
4.3.7.1- Ser
Ser é uma sub-classe da classe Representação Factual, identificando em qual tipo de
ser está classificado o componente, de acordo com os seguintes campos:
-
Tipo: o tipo de ser do componente; (homem, mulher, transformista, fictício);
-
Idade/Cronologia: qual a idade do componente ou em que faixa cronológica ele está;
(bebê, criança, adolescente, adulto, idoso, etc);
-
Cor: cor do componente.
4.3.7.2- Reino
Reino é uma sub-classe da classe Representação Factual, identificando em qual tipo de
reino está classificado o componente, de acordo com os seguintes campos:
-
Tipo: tipo de reino do componente; (reino animal, reino vegetal, reino mineral);
-
Nome: nome do reino ao qual pertence; por exemplo: cachorro, árvore;
71
-
Idade/Cronologia: qual a idade do componente ou em que faixa cronológica ele está;
(bebê, criança, adolescente, adulto, idoso, etc);
-
4.3.7.3- Força da Natureza
Força da Natureza é uma sub-classe da classe Representação Factual, identificando se
o componente da imagem é uma manifestação energética e outras vinculadas à natureza, por
meio do seguinte campo:
-
Nome: nome da manifestação da natureza.
4.3.7.4- Objeto
Objeto é uma sub-classe da classe Representação Factual, identificando se o
componente da imagem é um artefato ou manufatura, por meio dos seguintes campos:
-
Nome: nome do artefato ou manufatura;
-
4.3.8- Componentes Integrantes
Componentes Integrantes identificam os componentes considerados integrantes do ser,
isto é, os elementos que entram na composição, fazendo parte da caracterização do Ser.
Podem ser peças ou acessórios de indumentária, como por exemplo: óculos, chapéu, etc.;
esses serão descritos de acordo com os seguintes campos:
-
Nome: nome do componente integrante do ser;
72
-
Cor: cor do componente integrante do ser.
4.3.9- Componentes Não Integrantes
Componentes Não Integrantes identificam os componentes considerados não
integrantes do ser, como por exemplo, os componentes que o Ser estiver segurando ou
estiverem junto a ele, tal como: homem tocando violino. Esses serão descritos de acordo com
os seguintes campos:
-
Nome: nome do componente não integrante do ser;
-
Cor: cor do componente não integrante do ser.
Todas as propriedades das classes descritas anteriormente podem ter as seguintes
formas de captura, dependendo do método correspondente utilizado para a obtenção de seus
valores:
- Cabeçalho do Arquivo: a captura do valor da propriedade será feita diretamente por
meio dos descritores da imagem embutidos no próprio cabeçalho do arquivo da
imagem digital;
- Textual: a captura do valor da propriedade é feita de forma textual, a partir de
interação com o usuário, o valor da propriedade será digitado;
- Captura Automática: a captura do valor da propriedade será feita de forma
automática, como por exemplo, através de um algoritmo de rede neural.
A próxima seção apresenta descrições de imagens exemplos feitas a partir do modelo
conceitual de metadados proposto nesse capítulo.
73
4.4- EXEMPLOS UTILIZANDO O ESQUEMA
As Figuras 4.2, 4.3 e 4.4 apresentam o diagrama de instâncias de suas imagens
exemplo, sendo descritas através da utilização do esquema conceitual de metadados para
imagem especificado anteriormente.
Esta imagem (exemplo 1), criada já na forma digital (por isso não possui
representação na classe Imagem Original), representa uma paisagem e
contém os componentes: árvore, sol e mar. Podemos dar o nome de Paisagem
Natural a este objeto imagem, que será descrito através das classes Objeto
Imagem e Conteúdo Semântico, possuindo ainda duas versões deste objeto
(BMP e GIF). Dentro da classe Objeto Imagem serão descritas as
propriedades formato, direitos autorais, histograma de cor e textura. Na classe
Conteúdo Semântico são identificados: os componentes (Árvore, Sol, Mar)
existentes na Paisagem Natural e os tipos de categorias de conteúdo
semântico, conforme pode ser observado na Figura 4.2.
FIGURA 4.2: Diagrama de Instâncias da figura exemplo 1.
74
Esta imagem (exemplo 2), digitalizada a partir de uma
fotografia original, contém os componentes: bailarina e
bailarino. Recebe a denominação Foto de Ballet, e a
representação deste objeto imagem é descrito através das
classes Objeto Imagem e Conteúdo Semântico. Dentro
da classe Objeto Imagem serão descritas as propriedades
formato, digitalizador, data da criação e brilho. Na
classe Conteúdo Semântico são identificados: os
componentes (Bailarina e Bailarino) existentes na Foto
de Ballet e os tipos de categorias de conteúdo semântico.
Esta imagem possui um tipo de associação composto de
com o objeto imagem o5, conforme pode ser observado
na Figura 4.3.
Esta imagem (exemplo 3) recebe a denominação Rosto
de Bailarina e está associada a imagem anterior por
meio do tipo de relacionamento parte de. As descrições
referentes ao Conteúdo Semântico de o5 não estão sendo
representadas na Figura 4.3 e sim na Figura 4.4.
75
Alguns elementos descritores especificados nesse esquema podem ser identificados
nos padrões de metadados estudados no Capítulo 3 e também em sistemas estudados nas
abordagens do Capítulo 2. Por exemplo:
-
os elementos DC.title (título), DC.author (autor), entre outros elementos
descritores existentes no padrão Dublin Core são encontrados no esquema aqui
apresentado. Com a diferença de que no Dublin Core existem somente 15
76
elementos descritores no total, onde somente um deles (DC.description) serve para
a descrição de conteúdo semântico, enquanto que nesse esquema existe uma forma
mais detalhada para o tratamento desse tipo de informação semântica da imagem;
-
os elementos cor, textura e brilho existentes no sistema Excalibur e na maioria dos
sistemas estudados são encontrados também nesse esquema. Porém, além desses
esse esquema disponibiliza um conjunto de outros elementos, que também são
referentes à informação técnica da imagem;
-
o sistema AMORE permite a pesquisa por similaridade semântica por meio de seis
categorias temáticas (arts, movies, sports, travel, vehicles, wildlife), quando se
quer pesquisar imagens semanticamente similares à imagem que está selecionada
ele recupera as imagens que estão classificadas na mesma categoria que a imagem
selecionada. Enquanto que nesse esquema existe um tratamento mais detalhado
das características relacionadas ao conteúdo semântico da imagem. Além de
descrever os componentes contidos na imagem e os relacionamentos existentes
entre eles, identifica também os objetos imagem que são versões de outro objeto
imagem e os tipos de associações (composto de, parte de, derivado de) entre os
mesmos;
-
o sistema VIMSYS apresentado no Capítulo 2 define planos diferentes para a
representação das informações das imagens, mas não define com detalhe quais
elementos fazem parte de cada um desses planos.
O esquema proposto nesse capítulo vem então viabilizar uma representação
sistemática e detalhada dos elementos descritores de imagens estáticas digitais, incluindo
tanto elementos para descrever as informações técnicas da imagem quanto para descrever as
informações de conteúdo semântico, podendo com isso ser utilizado em arquiteturas de
metadados existentes.
77
CAPÍTULO 5
VISÃO GERAL SOBRE O PROTÓTIPO PARA BUSCA DE IMAGENS
Neste capítulo será apresentada a implementação do esquema conceitual de metadados
para documentação e recuperação de imagens apresentado no Capítulo 4, de forma a verificar
o seu funcionamento em um sistema isolado. Porém, este protótipo poderia ser utilizado
juntamente com outros sistemas, como os já estudados anteriormente nesta tese, e até com
mecanismos de busca existentes na Internet.
As classes do esquema foram implementadas no SGBDOO Jasmine (KHOSHAFIAN
et alii., 1998), um sistema gerenciador de banco de dados orientado a objetos e multimídia,
que possibilita o tratamento de dados do tipo imagem de forma mais natural do que nas
tecnologias relacionais convencionais. O SGBDOO Jasmine é um produto da empresa
Computer Associates (CAI, 1998), disponível em ambiente Windows NT e Solaris. Nesse
trabalho foi utilizada uma plataforma PC (2 GB HD, 166 MHZ, 64 KB de memória), com
sistema operacional Windows NT.
Para a implementação desse protótipo foram utilizadas duas ferramentas
disponibilizadas pelo próprio Jasmine, a saber: Jasmine Studio e WebLink. As etapas de
criação de classes e métodos, bem como a instanciação de objetos nas classes foram
desenvolvidas por meio do Jasmine Studio. A aplicação implementada para possibilitar
consultas às classes no ambiente Web foi desenvolvida utilizando-se o WebLink. WebLink é o
módulo que possibilita criar aplicações de acesso aos bancos de dados implementados no
Jasmine via Internet.
As próximas seções explicam mais detalhadamente os passos seguidos para a
implementação desse protótipo, mostrando também algumas das principais telas do ambiente
de prototipação.
78
5.1- CRIAÇÃO DAS CLASSES E MÉTODOS NO JASMINE
Nessa seção serão apresentados os passos seguidos para a criação das classes do
esquema proposto e dos métodos que possibilitam consultas às classes implementadas no
Jasmine. Explicam-se também alguns detalhes de utilização do Jasmine, de forma a facilitar o
entendimento sobre a criação de classes e métodos de um projeto. Além disso apresenta-se um
resumo da funcionalidade dos métodos criados em cada uma das classes do esquema,
implementadas nesse protótipo.
Após a criação de um Store e uma Class Family, conforme explicado no Apêndice C,
pode-se então iniciar a etapa de criação das classes e métodos de um projeto. A seção seguinte
mostra as classes e seus métodos implementados em ODQL pertencentes a esse protótipo.
5.1.1- Classes do Esquema Proposto e seus Métodos em ODQL
Após a criação da Class Family é possível criar as suas respectivas classes por meio
do Class Browser, tela disponibilizada pelo Jasmine Studio, ferramenta do Jasmine
mencionada anteriormente. Os métodos também podem ser criados, editados e compilados
dentro do Class Browser. Esse possibilita também a instanciação das classes. A Figura 5.1
apresenta a tela Class Browser com a hierarquia das classes do esquema de metadados para
imagem proposto no Capítulo 4.
79
FIGURA 5.1: Classes do Esquema implementadas no Jasmine Studio.
Conforme já mencionado, as classes são instanciadas por meio do Class Browser e as
consultas disponibilizadas por meio do WebLink, via Internet.
A linguagem de definição, manipulação e consulta aos objetos utilizada pelo Jasmine
é a ODQL (Object Database Query Language), utilizada na implementação de todos os
métodos.
A ODQL é baseada em consultas tipo SQL, apesar de não seguir a sua sintaxe padrão
para objetos. Um exemplo de consulta nessa linguagem pode ser visto a seguir, onde na
primeira linha boobjimg é uma variável declarada como um bag (coleção) do tipo
Objeto_Imagem, e na segunda linha boobjimg está recebendo todos os objetos da classe
Objeto_Imagem que possuem a propriedade formato=JPG:
$Bag <Objeto_Imagem> boobjimg;
$boobjimg = Objeto_Imagem from Objeto_Imagem where Objeto_Imagem.formato == “JPG”;
80
As páginas acessadas pela Internet por meio do WebLink foram programadas
utilizando a linguagem HTML com comandos ODQL embutidos, isto é, as páginas HTML
chamam métodos das classes escritos em ODQL.
Os métodos implementados em ODQL são todos para consultar às classes do esquema
de forma dinâmica. São disponibilizadas todas as propriedades de cada classe para que o
usuário possa fazer a consulta de acordo com a sua necessidade; a partir daí o método gera
dinamicamente a consulta por meio do comando stringCat() disponibilizado pelo Jasmine. Se
na consulta o campo referente à propriedade for preenchido pelo usuário com algum valor,
então essa propriedade entrará como condição da consulta. Um exemplo da utilização do
comando stringCat() pode ser visto na Figura 5.2.
FIGURA 5.2: Método exemplo utilizando o comando stringCat().
81
Algumas observações importantes devem ser feitas com relação à edição dos métodos
em ODQL: os comandos ODQL são identificados pela existência de um $ (dólar) na frente de
todos os comandos, que terminam sempre por ponto e vírgula (;). As linhas de comentários
são identificadas por iniciarem por /* (barra asterisco) e terminarem por */ (asterisco barra).
Os métodos das classes são chamados dentro das páginas HTML. Nelas são
disponibilizadas as propriedades das classes passadas como parâmentros para os seus
métodos.
Alguns dos métodos que efetuam consultas dinâmicas às classes de acordo com as
propriedades que forem escolhidas pelo usuário, podem ser visualizados no Apêndice A.
Todos os métodos recebem como parâmetros as propriedades da classe correspondente e
geram a cláusula Where da consulta dinamicamente de acordo com o preenchimento do
usuário, isto é, se a propriedade for diferente de branco (“ “) ela é concatenada à cláusula
Where por meio do comando stringCat( ). Em todas as consultas o resultado final corresponde
à imagens (propriedade arquivo_imagem_digital que está contida na classe Objeto_Imagem).
Todas as classes com seus respectivos métodos são apresentadas a seguir, sendo que somente
serão descritos os métodos que possuem funcionalidade um pouco diferente do que já foi
explicado acima:
•
Objeto Imagem:
− ConsultaInftec: nesse método não foi possível colocar todas as suas propriedades
como parâmetros, pois o editor de métodos do Jasmine Studio possui limitação
quanto ao número de linhas de código para a edição dos métodos. As duas
propriedades (dimensao_arquivo e dimensao_imagem) da classe Objeto_Imagem
que não puderam ser tratadas nesse método estão sendo tratadas pelo método
ConsultaDim. Outras três propriedades da classe Objeto_Imagem não estão sendo
consideradas nesse protótipo por necessitarem de métodos de captura automática
82
para a obtenção de seus valores. Essas propriedades são: textura, brilho e
histograma de cor.
− ConsultaDim: método que recebe como parâmetros as duas propriedades
(dimensao_arquivo e dimensao_imagem) da classe Objeto_Imagem. O template
(resultobjimg.html) criado para o tratamento de consultas à classe Objeto_Imagem
tratará adequadamente todas as propriedades da classe Objeto_Imagem chamando
os métodos ConsultaInftec e ConsultaDim. Todos os templates estão sendo
explicados na seção 5.2.3.
− ConsultaInter: esse método recebe como parâmetros o resultado do método
ConsultaInftec e do método ConsultDim e faz a interseção dos dois, retornando o
resultado final ao template (resultobjimg.html) que trata as consultas referentes à
classe Objeto_Imagem.
− Converte: método que recebe como parâmetro um campo do tipo String e converte
para Integer. Esse método foi necessário para ser utilizado em um dos templates
criados para a utilização da aplicação de consulta pela Internet utilizando o
WebLink.
•
Imagem Original:
− ConsultaOriginal.
•
Tipo de Associação:
− ConsultaTipo_associacao: essa consulta traz como resposta as imagens que
tenham o tipo de associação (composto de, parte de, derivado de) especificado na
consulta, bem como as imagens associadas a elas.
83
•
Conteúdo Semântico:
− ConsultaContsem_acao: método que recebe como parâmetros todas as
propriedades da classe Conteudo_Semantico que tiverem a propriedade Nome =
“Acao”.
− ConsultaContsem_espaco: método que recebe como parâmetros todas as
“Espaco”.
− ConsultaContsem_tempo: método que recebe como parâmetros todas as
“Tempo”.
− ConsultaContsem_finalidade: método que recebe como parâmetros todas as
“Finalidade”.
•
Tipo de Relacionamento:
− ConsultaTipo_relacionamento: método que tem como parâmetros as propriedades
descricao_generica, descricao_especifica e sobre da classe Componente e a
propriedade posicao da classe Tipo_de_Relacionamento, significando que poderão
ser pesquisadas imagens que tenham componentes com descrições determinadas, e
estando um componente em uma determinada posição em relação ao outro na
imagem. Esse método também possibilita a consulta a imagens que tenham
componentes em uma determinada posição sem ser dito na consulta com qual
outro componente ele está relacionado.
•
Representação Posicional:
− ConsultaRepre_pos: poderão ser pesquisadas imagens que tenham componentes
com a representação posicional de acordo com o que for descrito nos parâmetros.
84
Nos métodos das classes a seguir como não se pode precisar quantos objetos
pertencentes a cada uma das classes o usuário irá procurar, foi determinado nessa
implementação a disponibilização de até 3 objetos no máximo para a consulta, significando
que as propriedades das respectivas classes repetem-se 3 vezes, diferenciadas por uma
numeração (como exemplo: vide Figura 5.9).
•
Componente:
− ConsultaContsem_compo.
•
Ser:
− ConsultaRepre_fac_ser.
•
Reino:
− ConsultaRepre_fac_reino.
•
Força da Natureza:
− ConsultaRepre_fac_forca.
•
Objeto:
− ConsultaRepre_fac_objeto.
•
Componentes Integrantes:
− ConsultaCompo_int.
•
Componentes Não Integrantes:
− ConsultaCompo_nint.
Todos os métodos foram implementados utilizando a forma de captura textual para o
armazenamento dos valores das propriedades das classes, isto é, as classes são instanciadas a
partir da interação com o usuário, onde o valor da propriedade é digitado a partir do Jasmine
Studio. Não foi implementado nenhum método de captura automática de valor das
propriedades.
85
Alguns comandos importantes para a cópia e restauração de banco de dados criado no
Jasmine podem ser vistos no Apêndice C.
Na próxima seção será explicado mais detalhadamente o funcionamento da ferramenta
WebLink no contexto desse protótipo.
5.2- UTILIZAÇÃO DO WEBLINK COM O JASMINE
O WebLink (KHOSHAFIAN et alii., 1998), conforme visto na Figura 5.3, é uma
ferramenta disponibilizada pelo SGBDOO Jasmine que viabiliza a sua conexão via Internet.
O WebLink age como um servidor intermediário entre o servidor Web e o servidor de banco
de dados Jasmine.
FIGURA 5.3: Funcionamento do WebLink.
As próximas sub-seções mostrarão a arquitetura do WebLink, a configuração
necessária para a sua utilização, e ainda o funcionamento do protótipo implementado
utilizando o WebLink.
5.2.1- Arquitetura do WebLink
Aplicações WebLink consistem de um conjunto de templates. Esses templates são
páginas HTML (HyperText Markup Language) com marcações (tags) WebLink embutidas
para possibilitarem operações de dados armazenados no banco de dados Jasmine. Os tags
86
WebLink possibilitam a chamada de código ODQL embutido nas páginas HTML. A
arquitetura WebLink, como pode ser vista na Figura 5.4, provê três programas CGI (Common
Gateway Interface) para possibilitar o acesso aos templates. Os programas CGI são:
•
odb-login: esse programa inicia uma sessão WebLink e o acesso ao banco de dados
Jasmine. O servidor WebLink abre uma sessão com o banco de dados quando esse
programa é executado;
•
odb-get: esse programa requisita a execução de um template por meio da indicação
do nome do template;
•
odb-logout: esse programa termina a sessão WebLink e finaliza o acesso ao banco
de dados.
Após a edição do template o mesmo deve ser carregado dentro da Class Family
WebLink já existente no Jasmine. A Class Family WebLink contém a classe HTML_Template
onde são armazenadas todas as páginas HTML que são templates WebLink. A classe
HTML_Template contém métodos para manipulação de templates que servem para:
- criação: (HTML_Template.createTemplate(“nomedotemplate”, “localdoarquivo”));
- obtenção: (HTML_Template.getTemplate(“nomedotemplate”));
- execução: (HTML_Template.run(“nomedotemplate”)).
O CODQLIE (Client ODQL Interactive Environment) é um ambiente interativo que
além de servir para testar os métodos ODQL criados, serve também para a criação de
templates WebLink. Deve ser acessado pela linha de comando DOS, diretório
c:\jasmine\jasmine\bin, executando CODQLIE. Abaixo será mostrado um exemplo de
template de nome obj_img sendo criado. Estando já no CODQLIE, executar:
defaultCF WebLink;
HTML_Template.createTemplate(“obj_img”, “c:\\metaimagem\\templates\\obj_img.html”);
87
FIGURA 5.4: Arquitetura WebLink.
A Figura 5.4 mostra a arquitetura WebLink. Primeiro o comando odb-login é
executado para iniciar uma sessão WebLink, e a partir daí um número de requisições é
apresentado ao Servidor WebLink via chamadas odb-get. Todas essas classes são executadas
no contexto da mesma sessão. Finalmente, quando todas as requisições forem completadas, o
comando odb-logout termina a sessão. Na Class Family Weblink ficam armazenados todos os
templates criados na classe HTML_Template existente no WebLink.
Uma descrição passo a passo dos procedimentos necessários para configurar o
ambiente para a utilização do WebLink em Windows NT pode ser vista no Apêndice C.
5.2.2- Templates do Protótipo
Nessa seção serão descritas as funcionalidades dos templates criados na
implementação desse protótipo, e os códigos de alguns deles serão apresentados no Apêndice
B.
Apenas a página inicial (inicial.html), responsável pela abertura de uma sessão
WebLink, e a página home (home.html), não foram criadas como arquivos templates, isto é,
não foram criadas como templates na Class Family WebLink. Todos os demais arquivos
88
HTML foram criados como templates na classe HTML_Template existente na Class Family
WebLink. Para cada tela de consulta disponibilizada nesse protótipo existirá um template
correspondente.
No ambiente WebLink as variáveis que persistem enquanto a sessão estiver ativa são
identificadas como wit_nome, onde nome é o nome dado à variável. Nesta implementação foi
necessária a utilização dessas variáveis de forma a armazenar as respostas das consultas de
cada classe do esquema e ao final poder fazer uma interseção dessas respostas, no caso do
usuário desejar, em uma mesma consulta, obter propriedades de mais de uma classe. A
consulta a cada classe foi disponibilizada por um template diferente e com templates de
respostas dessas consultas também diferentes.
Os templates (como por exemplo: obj_img.html, compo.html) são responsáveis por
fazerem consultas às classes passando como parâmetros as respectivas propriedades das
classes, por meio do comando odb-get, ao template intermediário (por exemplo: objimginter.html) que disponibiliza dois botões, um que permite visualizar diretamente as imagens
respostas da consulta e o outro que permite continuar consultando em outras classes. Ao ser
escolhida diretamente a visualização das imagens respostas é chamado então o template result
(por exemplo: resultobjimg.html, resultcompo.html) correspondente, que exibe o resultado da
consulta. Se a escolha for continuar consultando entao a resposta da consulta é armazenada
em uma variável wit do tipo coleção (bag).
Nos
templates
(compo.html,
ser.html,
reino.html,
forca.html,
objeto.html,
compoint.html e componint.html) onde não se pode precisar quantos objetos da sua classe
correspondente o usuário irá procurar em uma imagem, foi determinado nessa implementação
a disponibilização de até 3 objetos no máximo para a consulta, onde as propriedades da
respectiva classe repetem-se 3 vezes, diferenciadas por uma numeração (como exemplo: vide
Figura 5.9).
89
Todos os templates de resultado (result) exibem as imagens (arquivo_imagem_digital
da classe Objeto_Imagem) respostas da consulta, disponibilizando, para cada imagem, dois
botões: um para a visualização de versões da imagem, mostradas pelo template
resultversoes.html, e o outro para a visualização das imagens associadas, mostradas pelo
template resultassoc-escolhido.html.
A seguir serão descritos os templates criados, juntamente com suas funcionalidades:
•
opcoes.html: contém as opções de consulta do protótipo, onde cada opção corresponde a
uma classe do esquema. Cada opção corresponde a um hiperlink para o template
correspondente, permitindo consultar às propriedades daquela classe.
•
obj_img.html: disponibiliza as propriedades da classe Objeto_Imagem de forma que estas
sejam preenchidas de acordo com a necessidade de consulta do usuário. Três propriedades
da classe Objeto_Imagem não estão sendo consideradas nesse protótipo por necessitarem
de métodos de captura automática para a obtenção de seus valores. Essas propriedades
são: textura, brilho e histograma de cor.
•
objimg-inter.html: faz chamada aos
métodos
ConsultaInftec,
ConsultaDim e
ConsultaInter pertencentes à classe Objeto_Imagem, passando como parâmetros as
variáveis wit recebidas do template obj_img.html aos métodos ConsultaInftec e
ConsultaDim. Esse template faz chamada a esses dois métodos ConsultaInftec e
ConsultaDim da classe Objeto_Imagem, pois, conforme já mencionado, as propriedades
dessa classe não puderam ser tratadas por um único método, já que o editor de métodos do
Jasmine Studio possui limitação quanto ao número de linhas de código. O objimginter.html faz chamada também ao método ConsultaInter para que possa então fazer a
interseção das respostas dos dois outros métodos executados anteriormente.
•
resultobjimg.html: exibe as imagens respostas da consulta feita em obj_img.html.
90
•
imgorig.html: disponibiliza todas as propriedades da classe Imagem_Original para que
sejam preenchidas de acordo com a necessidade de consulta do usuário.
•
imgorig-inter.html: faz chamada ao método ConsultaOriginal pertencente à classe
Imagem_Original, passando como parâmetros as variáveis wit recebidas do template
imgorig.html.
•
resultimgorig.html: exibe as imagens respostas da consulta feita em imgorig.html.
•
assoc.html: disponibiliza a propriedade tipo da classe Tipo_de_Associacao para que seja
preenchida de acordo com a necessidade de consulta do usuário.
•
assoc-inter.html: executa a consulta à classe Tipo_de_Associacao considerando a
variável wit recebida do template assoc.html.
•
resultassoc.html: exibe as imagens respostas da consulta feita em assoc.html, isto é, as
imagens que possuem o tipo de associacao especificado pelo usuário no template
assoc.html.
•
resultversoes.html: exibe como resultado as imagens que são versões da imagem
escolhida. Essa imagem é passada pelo template que chamou o resultversoes.html.
•
resultassoc-escolhido.html: exibe como resultado as imagens associadas à imagem
escolhida, dizendo ainda qual o tipo de associação existente. Essa imagem escolhida é
passada pelo template que chamou o resultasoc-escolhido.html, isto é, o template que o
chamou passa o valor do objeto_imagem escolhido.
•
acao.html: disponibiliza todas as propriedades da classe Conteudo_Semantico menos a
propriedade nome que já está = “Acao”, para que sejam preenchidas de acordo com a
necessidade de consulta do usuário.
•
acao-inter.html: faz chamada ao método ConsultaContsem_acao pertencente à classe
Conteudo_Semantico, passando como parâmetros as variáveis wit recebidas do template
acao.html.
91
•
resultacao.html: exibe as imagens respostas da consulta feita em acao.html.
•
espaco.html: disponibiliza todas as propriedades da classe Conteudo_Semantico menos a
propriedade nome que já está sendo considerada igual a “Espaco”, para que sejam
preenchidas de acordo com a necessidade de consulta do usuário.
•
espaco-inter.html: faz chamada ao método ConsultaContsem_espaco pertencente à classe
espaco.html.
•
resultespaco.html: exibe as imagens respostas da consulta feita em espaco.html.
•
tempo.html: disponibiliza todas as propriedades da classe Conteudo_Semantico menos a
propriedade nome que já está = “Tempo”, para que sejam preenchidas de acordo com a
•
tempo-inter.html: faz chamada ao método ConsultaContsem_tempo pertencente à classe
tempo.html.
•
resulttempo.html: exibe as imagens respostas da consulta feita em tempo.html.
•
finali.html: disponibiliza todas as propriedades da classe Conteudo_Semantico menos a
propriedade nome que já está = “Finalidade”, para que sejam preenchidas de acordo com a
•
finali-inter.html: faz chamada ao método ConsultaContsem_finali pertencente à classe
finali.html.
•
resultfinali.html: exibe as imagens respostas da consulta feita em finali.html.
•
compo.html: disponibiliza todas as propriedades da classe Componente menos a
propriedade nome que já está = “Componente”, para que sejam preenchidas de acordo
com a necessidade de consulta do usuário.
92
•
compo-inter.html: faz chamada ao método ConsultaContsem_compo pertencente à classe
Componente, passando como parâmetros as variáveis wit recebidas do template
compo.html.
•
resultcompo.html: exibe as imagens respostas da consulta feita em compo.html.
•
relac.html:
disponibiliza
todas
as
propriedades
das
classes
Componente
e
Tipo_de_Relacionamento, para que sejam preenchidas de acordo com a necessidade de
consulta
do
usuário,
onde
aparecem
as
propriedades
descricao_generica,
descricao_especifica e sobre da classe Componente e a propriedade posicao da classe
Tipo_de_Relacionamento. Poderão ser pesquisadas imagens que tenham componentes
com descrições determinadas, estando um componente em uma determinada posição em
relação ao outro na imagem. Também possibilita a consulta à imagens que tenham
componentes em uma determinada posição na imagem sem ser dito na consulta com qual
outro componente ele está relacionado.
•
relac-inter.html: faz chamada ao método ConsultaTipo_relacionamento pertencente à
classe Tipo_de_Relacionamento, passando como parâmetros as variáveis wit recebidas do
template relac.html.
•
resultrelac.html: exibe as imagens respostas da consulta feita em relac.html.
•
rpos.html: disponibiliza todas as propriedades das classes Representacao_Posicional, para
que sejam preenchidas de acordo com a necessidade de consulta do usuário.
•
rpos-inter.html: faz chamada ao método ConsultaRepre_pos pertencente à classe
Representacao_Posicional, passando como parâmetros as variáveis wit recebidas do
template rpos.html.
•
resultrpos.html: exibe as imagens respostas da consulta feita em rpos.html.
•
ser.html: disponibiliza todas as propriedades da classe Ser, para que sejam preenchidas de
acordo com a necessidade de consulta do usuário.
93
•
ser-inter.html: faz chamada ao método ConsultaRepre_fac_ser pertencente à classe Ser,
passando como parâmetros as variáveis wit recebidas do template ser.html.
•
resultser.html: exibe as imagens respostas da consulta feita em ser.html.
•
reino.html: disponibiliza todas as propriedades da classe Reino, para que sejam
•
reino-inter.html: faz chamada ao método ConsultaRepre_fac_reino pertencente à classe
Reino, passando como parâmetros as variáveis wit recebidas do template reino.html.
•
resultreino.html: exibe as imagens respostas da consulta feita em reino.html.
•
forca.html: disponibiliza todas as propriedades da classe Forca_da_Natureza, para que
sejam preenchidas de acordo com a necessidade de consulta do usuário.
•
forca-inter.html: faz chamada ao método ConsultaRepre_fac_forca pertencente à classe
Forca_da_Natureza, passando como parâmetros as variáveis wit recebidas do template
forca.html.
•
resultforca.html: exibe as imagens respostas da consulta feita em forca.html.
•
objeto.html: disponibiliza todas as propriedades da classe Objeto, para que sejam
•
objeto-inter.html: faz chamada ao método ConsultaRepre_fac_objeto pertencente à
classe Objeto, passando como parâmetros as variáveis wit recebidas do template
objeto.html.
•
resultobjeto.html: exibe as imagens respostas da consulta feita em objeto.html.
•
compoint.html: disponibiliza todas as propriedades da classe Componentes_Integrantes,
para que sejam preenchidas de acordo com a necessidade de consulta do usuário.
•
compoint-inter.html: faz chamada ao método ConsultaCompo_int pertencente à classe
Componentes_Integrantes, passando como parâmetros as variáveis wit recebidas do
template compoint.html.
94
•
resultcompoint.html: exibe as imagens respostas da consulta feita em compoint.html.
•
componint.html:
disponibiliza
todas
as
propriedades
da
classe
Componentes_Nao_Integrantes, para que sejam preenchidas de acordo com a necessidade
de consulta do usuário.
•
componint-inter.html: faz chamada ao método ConsultaCompo_nint pertencente à classe
Componentes_Nao_Integrantes, passando como parâmetros as variáveis wit recebidas do
template componint.html.
•
resultcomponint.html: exibe as imagens respostas da consulta feita em componint.html.
•
resultfim.html: exibe o resultado final das consultas feitas às várias classes
disponibilizadas no template opcoes.html, pois o usuário pode querer em uma mesma
consulta pesquisar propriedades de classes diferentes. Esse template faz a interseção de
todas as respostas das consultas feitas à cada classe. Essas respostas foram sendo
armazenadas em variáveis wit (que permanecem enquanto a sessão WebLink estiver ativa)
para que agora nesse template pudessem ser utilizadas na interseção.
•
todas.html: exibe todas as imagens armazenadas na classe Objeto_Imagem.
Essa seção explicou a funcionalidade de todos os templates implementados nesse
protótipo, onde alguns dos códigos completos estão disponibilizados no Apêndice B. A
próxima seção explica alguns detalhes importantes da interface desse protótipo, mostrando
alguns exemplos de consultas via Internet utilizando o WebLink por meio dos templates
anteriormente descritos.
5.3- INTERFACE DE CONSULTA AOS METADADOS DAS IMAGENS
Nessa seção será descrito o funcionamento do protótipo implementado. Primeiramente
será mostrado como é disponibilizada a inclusão, alteração e exclusão de imagens nas classes
95
do esquema. Em seguida explica como são disponibilizadas as consultas às classes via
Internet utilizando o WebLink.
As inclusões, alterações e exclusões de instâncias nas classes não estão
disponibilizadas via Internet, podendo ser feitas somente pela tela Class Browser do Jasmine
Studio. A Figura 5.5 mostra uma tela exemplo, que serve tanto para inclusão como para
alteração na classe Componentes_Integrantes utilizando o Jasmine Studio. Nessa tela
aparecem as propriedades da classe do lado esquerdo e, ao selecionar cada propriedade,
aparece então do lado direito, o respectivo espaço para o preenchimento do valor
correspondente. A exclusão é feita diretamente ao selecionar o objeto desejado e escolhendose a opção delete ou pressionando diretamente a tecla del do teclado.
FIGURA 5.5: Tela exemplo de inclusão utilizando o Jasmine Studio.
Já as consultas às classes podem ser feitas via Internet utilizando o WebLink. A
primeira tela (inicial.html) dessa aplicação que disponibiliza consultas via Internet é mostrada
na Figura 5.6; a segunda tela (home.html) é apresentada na Figura 5.7; e a tela das opções
(opcoes.html) disponíveis para consultar às classes do esquema é mostrada na Figura 5.8.
Todas essas páginas html foram explicadas na seção 5.2.3 e alguns códigos completos podem
ser encontrados no Apêndice B.
96
FIGURA 5.6: Primeira tela (inicial.html) da aplicação via Internet.
FIGURA 5.7: Segunda tela (home.html) da aplicação via Internet.
97
FIGURA 5.8: Tela (opcoes.html) com as opções de consulta da aplicação via Internet.
A Figura 5.9 apresenta a tela (compo.html) em uma consulta à classe Componente. A
Figura 5.10 mostra o resultado (resultcompo.html) da consulta feita na tela da Figura 5.9.
FIGURA 5.9: Consulta à classe Componente (compo.html).
98
FIGURA 5.10: Resposta à consulta (resultcompo.html) feita na Figura 5.9.
A Figura 5.11 mostra o resultado das imagens associadas à imagem da Figura 5.10.
Clicando-se o botão Associações daquela figura, o resultado aparece na Figura 5.11.
FIGURA 5.11: Resposta às associações (resultassoc-escolhido.html) da Figura 5.10.
99
A Figura 5.12 mostra uma tela (obj_img.html) de uma consulta a imagens da classe
Objeto_Imagem e a Figura 5.13 apresenta o resultado (resultobjimg.html) da consulta feita na
Figura 5.12.
FIGURA 5.12: Consulta à classe Objeto_Imagem (obj_img.html).
FIGURA 5.13: Resposta à consulta (resultobjimg.html) feita na Figura 5.12.
100
Esse capítulo descreveu a etapa de implementação do protótipo, totalmente baseado na
especificação do esquema conceitual para documentação e recuperação de imagens proposto
nesse trabalho.
Nesse protótipo todos os métodos foram implementados utilizando a forma de captura
textual para o armazenamento dos valores das propriedades das classes, isto é, as classes são
instanciadas a partir da interação com o usuário, onde o valor da propriedade é digitado a
partir do Jasmine Studio.
Embora não tenha sido implementado nenhum método de captura automática do valor
das propriedades, esse protótipo poderia ser utilizado juntamente com técnicas das outras
abordagens estudadas, para constituirem um meio mais rico de recuperação de imagens.
Poderia certamente ter sido definido um conjunto mais completo de métodos que permitissem
capturar características das imagens de forma automática. Como por exemplo, poderiam ser
obtidos os valores das propriedades: formato, dimensão do arquivo, esquema de compressão,
entre outros, do cabeçalho do arquivo como acontece no formato PNG, descrito no Capítulo 2.
Ou ainda, um outro exemplo seria o valor da propriedade textura que poderia estar sendo
capturado automaticamente, por meio de algoritmos de redes neurais normalmente utilizados
entre as técnicas de Inteligência Artificial.
O
ambiente
completamente
distribuído
provido
pela
Internet
requer
a
interoperabilidade entre padrões e implementações existentes, requisitos importantes para a
extensibilidade e adaptação de modelos e metamodelos. Para que o esquema implementado
por esse protótipo possa ser integrado a outros sistemas e mecanismos de busca faz-se
necessária a utilização da XML (Extensible Markup Language), que é uma tecnologia que
101
têm sido utilizada como padrão para disponibilizar recursos no ambiente WWW. O Apêndice
D apresenta uma descrição conceitual da linguagem XML e uma abordagem do sistema
segundo a visão XML, a partir do exemplo de algumas classes do esquema proposto sendo
descritas segundo essa sintaxe.
O próximo capítulo finaliza esse trabalho apresentando a conclusão desse estudo e as
suas principais contribuições para possíveis trabalhos futuros.
102
CAPÍTULO 6
CONCLUSÃO
Com a evolução tecnológica que cada vez mais aproxima o homem do computador
tornando esta interface de comunicação mais fácil e amigável, cresce a tendência de
transformar todos os tipos de informação em meio digitalizado, tornando-os acessíveis e
disponíveis computacionalmente.
Algumas empresas já estão disponibilizando seus dados (em vários tipos de mídias)
em ambientes automatizados, onde informações em forma de papel, vídeo, filme ou fita agora
já podem ser acessadas computacionalmente. Porém, a maioria destas informações vêm sendo
disponibilizadas sem nenhuma padronização, onde não existe nenhum critério para a
descrição de seus conteúdos, requisito de fundamental importância para a utilização eficaz das
informações ali armazenadas. Metadados, também descritos como dados sobre dados, têm
sido alvo de pesquisa de vários grupos internacionais, pois preocupa-se com a padronização e
veiculação de recursos em repositórios heterogêneos de dados.
No caso das mídias do tipo imagem estática digitalizada ainda não existe um consenso
de como se especificar metadado de forma padronizada mundialmente. Existem dois padrões
de metadados, tais como o Dublin Core (BROSS, 1997) e o SAIF (SAIF) estudados no
Capítulo 3, que possibilitam descrever imagens estáticas, porém limitados à descrição de
algumas de suas características. Existem também formatos de arquivo de imagem, como o
PNG (ROELOFS, 1997) e o SPIFF (SPIFF, 1995), apresentados no Capítulo 2, que
possibilitam embutir metadados dentro do próprio cabeçalho do arquivo da imagem.
Igualmente ao caso anterior, nenhum desses padrões e formatos possibilitam descrever
totalmente as características da imagem.
103
Outro fato muito importante que não tem sido levado em consideração na descrição
das imagens é o conteúdo semântico. O que existe de verdadeiramente importante em dados
do tipo imagem é o seu consteúdo semântico, isto é, informações contidas na imagem. Porém,
essas informações de escopo semântico não vêm tendo a importância que merecem, pois
dados do tipo imagem têm sido vistos como meros arquivos que possuem tamanho, formato,
cores, entre outras informações meramente técnicas de um arquivo.
Para a descrição do conteúdo semântico das imagens no escopo desse trabalho foram
estudadas as descrições de imagens estáticas digitais dentro das abordagens de Ciência da
Computação (SHAH et alii., 1997) (CHANG et alii., 1997) (GUPTA, 1997) (QBIC, 1997)
(GROSKY, 1997) (LORENZ, 1997) (GUPTA et alii., 1991) (AMORE, 1998) (EXCALIBUR,
1998) (HERMES et alii, 1995) (MEYER, 1997), apresentadas no Capítulo 2, como também
foram pesquisadas e incluídas no Capítulo 4 as formas de catalogação e descrição de imagens
na área de Ciência da Informação (PANOFSKY, 1979) (SHATFORD, 1986) (CORDEIRO,
1990) (SMIT, 1996) (FUNARTE, 1998), já que esta também é uma área que se preocupa com
esse tema. Esse estudo levou à conclusão de que não existe uma padronização de fato para a
descrição de imagens estáticas de forma genérica, já que os pesquisadores na área de Ciência
da Informação trabalham de acordo com o acervo a ser descrito, não existindo uma
categorização formal que sirva para a descrição de uma imagem qualquer.
Percebe-se claramente a necessidade da especificação sistemática e detalhada de
metadados apropriados às imagens que descrevam tanto as suas caraterísticas relacionadas à
informação técnica quanto às caraterísticas relacionadas ao seu conteúdo semântico.
104
6.1- PRINCIPAIS CONTRIBUIÇÕES
Esse trabalho tem como principal contribuição o desenvolvimento de uma modelagem
conceitual que permite a descrição e recuperação de imagens, através do estudo e
sistematização das características das imagens. As classes pertencentes ao esquema conceitual
decorrente dessa modelagem viabilizam a documentação de uma imagem estática do tipo
fotografia, pintura ou gravura qualquer, descrevendo suas propriedades, os componentes
contidos na imagem e os relacionamentos existentes entre eles. Esses descritores permitem
também identificar os objetos imagem que são versões de outro objeto imagem e os tipos de
O esquema proposto descreve tanto as informações técnicas quanto as informações
relacionadas ao conteúdo semântico da imagem, contribuindo com uma especificação
sistemática e detalhada dos elementos descritores de imagens estáticas digitais, podendo com
isso serem utilizados em arquiteturas de metadados existentes.
A especificação desse esquema foi base para a implementação de um protótipo de
aplicação apresentado no Capítulo 5, em um ambiente que possibilita a descrição e
recuperação de imagens baseadas em seus descritores utilizando um SGBDOO denominado
Jasmine (CAI, 1998) (KHOSHAFIAN et alii., 1998). Esse ambiente possibilita ainda que as
imagens sejam consultadas a partir dos seus respectivos metadados no ambiente Internet por
meio de uma ferramenta do próprio Jasmine, denominada WebLink. Outra contribuição além
do protótipo implementado, foi o estudo da utilização do Jasmine, um SGBDOO bastante
recente, e do WebLink.
105
6.2- SUGESTÕES PARA TRABALHOS FUTUROS
Podem ser sugeridos alguns trabalhos que possivelmente darão continuidade a esse:
•
Estender o esquema proposto, que visa somente a documentação e recuperação de
imagens estáticas digitais, de forma a tratar também as imagens em movimento (vídeo);
•
Disponibilizar o esquema proposto para que outros sistemas e mecanismos de busca da
Internet possam utilizá-lo, para isso utilizar a XML (eXtensible Markup Language)
(LIGHT, 1999) verificando a possibilidade de ligação a um SGBD; uma explicação sobre
a XML pode ser encontrada no Apêndice D, juntamente com um exemplo de algumas
classes do esquema proposto sendo descritas segundo a sintaxe XML;
•
Estender o protótipo implementado para possibilitar, além de consultas às classes pela
Internet, a inclusão, alteração e exclusão de instâncias das classes também nesse ambiente;
•
Estender o protótipo implementado para tratar as propriedade das classes de forma que
possam também ser capturadas automaticamente, a exemplo de histogramas de cor,
textura, etc. Esse protótipo contêm métodos que permitem somente capturar os valores das
propriedades de forma textual, a partir da digitação de valores.
106
APÊNDICE A
ALGUNS DOS MÉTODOS EM ODQL
A funcionalidade de todos os métodos desse apêndice está sendo descrita no Capítulo 5.
Método da classe Objeto_Imagem:
•
ConsultaInter
metaimagemCF::Objeto_Imagem::ConsultaInter
Method: ConsultaInter
Level: Class
Return Value: metaimagemCF::Objeto_Imagem
Collection
Parameters:
bodimen
metaimagemCF::Objeto_ImagemCollection
botec
metaimagemCF::Objeto_ImagemCollection
$defaultCF 'metaimagemCF';
$Bag <Objeto_Imagem> borfim;
$borfim = Bag{};
$borfim = bodimen.intersect(botec);
$return(borfim);
Método da classe Conteudo_Semantico:
•
ConsultaContsem_acao
metaimagemCF::Conteudo_Semantico::ConsultaContsem_acao
Method: ConsultaContsem_acao Level: Class
Collection
Parameters:
generica String [40]
especifica String [40]
sobre String [40]
$String w_clause;
$String qry;
$String aux;
$Bag <Objeto_Imagem> boacao;
$w_clause = "";
$aux = "Acao";
$boacao = Bag{};
$if (generica!="" or especifica!="" or sobre!="") {
$w_clause = "Conteudo_Semantico.nome==\"";
$w_clause = w_clause.stringCat(aux);
$w_clause = w_clause.stringCat("\"");
};
$if (generica!="") {
$w_clause = w_clause.stringCat("\ and Conteudo_Semantico.de_generico==\"");
$w_clause = w_clause.stringCat(generica);
};
$if (especifica!="") {
$w_clause = w_clause.stringCat("\ and Conteudo_Semantico.de_especifico==\"");
$w_clause = w_clause.stringCat(especifica);
};
$if (sobre!="") {
$w_clause = w_clause.stringCat("\ and Conteudo_Semantico.sobre==\"");
$w_clause = w_clause.stringCat(sobre);
};
$qry = String.format("boacao = Conteudo_Semantico.objeto_imagem from Conteudo_Semantico where %s;", w_clause);
$execute qry using boacao;
$return(boacao);
107
Método da classe Componente:
•
ConsultaContsem_compo
metaimagemCF::Componente::ConsultaContsem_compo
Method: ConsultaContsem_compo
Level: Class
Collection
Parameters:
generica1 String [40]
especifica1 String [40]
sobre1 String [40]
sobre2 String [40]
sobre3 String [40]
$String w_clause1;
$String w_clause2;
$String w_clause3;
$String qry1;
$String qry2;
$String qry3;
$Bag <Objeto_Imagem> bocompo1;
$Bag <Objeto_Imagem> resultadop1;
$Bag <Objeto_Imagem> resultado;
$w_clause1 = "";
$w_clause2 = "";
$w_clause3 = "";
$bocompo1 = Bag{};
$bocompo2 = Bag{};
$bocompo3 = Bag{};
$resultado = Bag{};
$resultadop1 = Bag{};
$if (generica1!="") {
$w_clause1 = w_clause1.stringCat("\Componente.de_generico==\"");
$w_clause1 = w_clause1.stringCat(generica1);
$w_clause1 = w_clause1.stringCat("\"");
};
$if (especifica1!="") {
$if (w_clause1=="") {
$w_clause1 = w_clause1.stringCat("\Componente.de_especifico==\"");
$w_clause1 = w_clause1.stringCat(especifica1);
}
else if (w_clause1!="")
{
$w_clause1 = w_clause1.stringCat("\ and Componente.de_especifico==\"");
};
};
$if (sobre1!="") {
$w_clause1 = w_clause1.stringCat("\Componente.sobre==\"");
$w_clause1 = w_clause1.stringCat(sobre1);
}
{
$w_clause1 = w_clause1.stringCat("\ and Componente.sobre==\"");
};
};
};
108
}
{
};
};
$if (sobre2!="") {
}
{
};
};
};
}
{
};
};
$if (sobre3!="") {
}
{
};
};
$if (w_clause1!="") {
$qry1 = String.format("bocompo1 = Componente.objeto_imagem from Componente where %s;", w_clause1);
$execute qry1 using bocompo1;
};
};
};
$if (w_clause1!="" and w_clause2=="" and w_clause3=="") {
$resultado = bocompo1;
109
};
$if (w_clause1=="" and w_clause2!="" and w_clause3=="") {
};
$if (w_clause1=="" and w_clause2=="" and w_clause3!="") {
};
$if (w_clause1!="" and w_clause2!="" and w_clause3=="") {
$resultado = bocompo1.intersect(bocompo2);
};
$if (w_clause1!="" and w_clause2=="" and w_clause3!="") {
};
$if (w_clause1=="" and w_clause2!="" and w_clause3!="") {
};
$if (w_clause1!="" and w_clause2!="" and w_clause3!="") {
$resultadop1 = bocompo1.intersect(bocompo2);
$resultado = resultadop1.intersect(bocompo3);
};
$return(resultado);
Método da classe Tipo_de_Relacionamento:
•
ConsultaTipo_relacionamento
metaimagemCF::Tipo_de_Relacionamento::ConsultaTipo_relacionamento
Method: ConsultaTipo_relacionamento
Level: Class
Collection
Parameters:
sobre1 String [40]
relaciona1 String [30]
sobre2 String [40]
$String w_clause1;
$String w_clause2;
$String qry1;
$String qry2;
$Bag <Componente> bocompo1;
$Componente compo1;
$Bag <Componente> bocompo2;
$Componente compo2;
$Bag <Componente> bocompoaux2;
$Componente compoaux2;
$Bag <Tipo_de_Relacionamento> borelaciona;
$Tipo_de_Relacionamento rel;
$w_clause1 = "";
$w_clause2 = "";
$bocompo1 = Bag{};
$bocompo2 = Bag{};
$bocompoaux2 = Bag{};
$resultado = Bag{};
};
}
110
{
};
};
$if (sobre1!="") {
}
{
};
};
};
}
{
};
};
$if (sobre2!="") {
}
{
};
};
$qry1 = String.format("bocompo1 = Componente from Componente where %s;", w_clause1);
};
$qry2 = String.format("bocompo2 = Componente from Componente where %s;", w_clause2);
};
$if (w_clause1!="" and w_clause2!="") {
$scan (bocompo1, compo1) {
$borelaciona = compo1.relacionado_com;
$scan (borelaciona, rel) {
$if (rel.posicao == relaciona1) {
$bocompoaux2 = rel.componentes_relacionados;
$scan (bocompoaux2, compoaux2) {
$if (compo2 == compoaux2) {
$resultado = resultado.add(compo1.objeto_imagem);
};
};
111
};
};
};
};
};
$if (w_clause1!="" and w_clause2=="") {
$borelaciona = compo1.relacionado_com;
$scan (borelaciona, rel) {
$if (rel.posicao == relaciona1) {
$resultado = resultado.add(compo1.objeto_imagem);
};
};
};
};
$return(resultado);
Método da classe Ser:
•
ConsultaRepre_fac_ser
metaimagemCF::Ser::ConsultaRepre_fac_ser
Method: ConsultaRepre_fac_ser Level: Class
Parameters:
tipo1 String [20]
idade1 String [15]
cor1 String [15]
tipo2 String [20]
idade2 String [15]
cor2 String [15]
tipo3 String [20]
idade3 String [15]
cor3 String [15]
$String w_clause1;
$String w_clause2;
$String w_clause3;
$String qry1;
$String qry2;
$String qry3;
$Bag <Objeto_Imagem> bocomposer1;
$Bag <Objeto_Imagem> resultadop1;
$w_clause1 = "";
$w_clause2 = "";
$w_clause3 = "";
$bocomposer1 = Bag{};
$resultadop1 = Bag{};
$resultado = Bag{};
Collection
$if (tipo1!="") {
$w_clause1 = "Componente.ser.tipo==\"";
$w_clause1 = w_clause1.stringCat(tipo1);
};
$if (idade1!="") {
$w_clause1 = "Componente.ser.idade==\"";
$w_clause1 = w_clause1.stringCat(idade1);
}
{
$w_clause1 = w_clause1.stringCat("\ and Componente.ser.idade==\"");
};
112
};
$if (cor1!="") {
$w_clause1 = "Componente.ser.cor==\"";
$w_clause1 = w_clause1.stringCat(cor1);
}
{
$w_clause1 = w_clause1.stringCat("\ and Componente.ser.cor==\"");
};
};
$if (tipo2!="") {
};
$if (idade2!="") {
}
{
};
};
$if (cor2!="") {
}
{
};
};
$if (tipo3!="") {
};
$if (idade3!="") {
}
{
};
};
$if (cor3!="") {
}
{
113
};
};
$qry1 = String.format("bocomposer1 = Componente.objeto_imagem from Componente where %s;", w_clause1);
$execute qry1 using bocomposer1;
};
};
};
$if (w_clause1!="" and w_clause2=="" and w_clause3=="") {
$resultado = bocomposer1;
};
$if (w_clause1=="" and w_clause2!="" and w_clause3=="") {
};
$if (w_clause1=="" and w_clause2=="" and w_clause3!="") {
};
$if (w_clause1!="" and w_clause2!="" and w_clause3=="") {
$resultado = bocomposer1.intersect(bocomposer2);
};
$if (w_clause1!="" and w_clause2=="" and w_clause3!="") {
};
$if (w_clause1=="" and w_clause2!="" and w_clause3!="") {
};
$if (w_clause1!="" and w_clause2!="" and w_clause3!="") {
$resultadop1 = bocomposer1.intersect(bocomposer2);
$resultado = resultadop1.intersect(bocomposer3);
};
$return(resultado);
114
APÊNDICE B
ALGUNS ARQUIVOS HTML COM CÓDIGO ODQL EMBUTIDO
A funcionalidade de todos esses arquivos HTML desse apêndice está sendo descrita no
Capítulo 5.
•
inicial.html
<html>
<head>
<title>Tese de Mestrado - IME - Aluna: Simone de Souza Garcia</title>
</head>
<body LINK="#0000FF" VLINK="#800080" background="/metaimagem/gifs/BLUEBACK.gif"
bgproperties="fixed">
<h1 align="center"><img src="/metaimagem/gifs/anima.gif" width="64" height="93" alt="IME"
align="left"></h1>
<blockquote>
<blockquote>
<div align="center"><center><address>
<strong><small><font face="Times New Roman">Ministério do Exército</font> </small></strong>
</address>
</center></div><div align="center"><center><address>
<strong><small><font face="Times New Roman">Instituto Militar de Engenharia</font> - IME </small></strong>
</address>
</center></div><div align="center"><center><address>
<small><strong><font face="Times New Roman">Departamento de Engenharia de Sistemas e
Computação - DE/9</font></strong> </small>
</address>
</center></div><p align="center"><big><font color="#0000FF"><strong> </strong></font></big></p>
<div align="center"><center><address>
<font color="#0000FF"><strong><big>Tese de Mestrado</big><small> </small></strong></font>
</address>
</center></div>
</blockquote>
</blockquote>
<div align="center"><center>
<address>
<big><big><font face="Times New Roman"><a href="/cgi-bin/odb-login.exe?WIT_env=metaimagem">Metadados
para </a></font></big></big>
</address>
</center></div><a href="/cgi-bin/odb-login.exe?WIT_env=metaimagem"><div align="center"><center>
<address>
<big><big><font face="Times New Roman">Documentação e Recuperação de Imagens</font></big></big><small>
</small>
</address>
</center></div></a>
<p align="center"><strong><small><span style="border: medium none"> </span></small></strong></p>
<div align="center"><center>
<address>
<strong><small><span style="border: medium none">Aluna: Simone de Souza Garcia</span></small></strong>
</address>
</center></div><div align="center"><center>
<address>
<small><span style="border: medium none">Área de Concentração: Tratamento da
Informação  -  Linha de Pesquisa: Sistemas de Bancos de Dados</span></small>
</address>
</center></div><div align="center"><center>
<address>
<small><span style="border: medium none">Orientadora: Ana Maria de Carvalho Moura
             Coorientadora:
115
Maria Luíza Machado Campos</span></small>
</address>
</center></div>
</body>
</html>
•
home.html
<html>
<head>
</head>
bgproperties="fixed">
<font SIZE="6" COLOR="#0000ff">
<h2 ALIGN="CENTER">Metadados para Imagens</h2>
</font>
<h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=temp1">Consultando Banco de Dados de
Imagens Utilizando Metadados</a></h4>
<hr width="80%" color="#800000">
<p align="center">
<a href="/cgi-bin/odb-logout.exe?WIT_html=/metaimagem/html/inicial.html" target="_top"><img
src="/metaimagem/gifs/exits.bmp" WIDTH="31" HEIGHT="31" border="0" alt="Sair" width="84" height="30"></a> </p>
<hr width="80%" color="#800000">
</body>
</html>
•
opcoes.html
<html>
<head>
</head>
bgproperties="fixed" style="text-indent: 0px; letter-spacing: 0px">
<h4 ALIGN="CENTER"><font size="5" color="#0000FF">Metadados para Imagens</font></h4>
<table border="1" width="100%" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF"
bordercolordark="#FFFFFF" cellspacing="0">
<tr>
<td width="55%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=obj_img">Objeto Imagem</a></h4>
</td>
<td width="53%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=imgorig">Imagem Original</a></h4>
</td>
</tr>
<tr>
<td width="54%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=assoc">Tipo de Associação
</a></h4>
</td>
<td width="54%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=todas">Todas as Imagens</a></h4>
</td>
</tr>
<tr>
<td width="55%" valign="top"><h4>Conteúdo Semântico</h4>
<h4>         <a
HREF="/cgi-bin/odb-get.exe?WIT_template=acao">Ação</a></h4>
<h4>         <a
HREF="/cgi-bin/odb-get.exe?WIT_template=espaco">Espaço</a></h4>
<h4>         <a
HREF="/cgi-bin/odb-get.exe?WIT_template=tempo">Tempo</a></h4>
<h4>         <a
HREF="/cgi-bin/odb-get.exe?WIT_template=finali">Finalidade</a></h4>
<h4>         <a
HREF="/cgi-bin/odb-get.exe?WIT_template=compo">Componente</a></h4>
</td>
<td width="53%"><h4>Representação Factual  </h4>
<h4>       <a
HREF="/cgi-bin/odb-get.exe?WIT_template=ser">Ser</a></h4>
116
<h5>             
     <a HREF="/cgi-bin/odb-get.exe?WIT_template=compoint">Componentes
Integrantes</a></h5>
<h5>            
      <a HREF="/cgi-bin/odb-get.exe?WIT_template=componint">Componentes
Não Integrantes</a></h5>
<h4>       <a
HREF="/cgi-bin/odb-get.exe?WIT_template=reino">Reino</a></h4>
<h4>       <a
HREF="/cgi-bin/odb-get.exe?WIT_template=forca">Força da Natureza</a></h4>
<h4>       <a
HREF="/cgi-bin/odb-get.exe?WIT_template=objeto">Objeto</a></h4>
</td>
</tr>
<tr>
<td width="55%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=relac">Relacionamento entre
Componentes</a></h4>
</td>
<td width="53%"><h4><a HREF="/cgi-bin/odb-get.exe?WIT_template=rpos">Representação
Posicional</a></h4>
</td>
</tr>
</table>
<p align="center"><a HREF="/cgi-bin/odb-get.exe?WIT_template=resultfim"><img
src="/metaimagem/gifs/finaliz.bmp" WIDTH="84" HEIGHT="32" border="0"
alt="Resultado Final de Todas as Consultas" width="84" height="32"></a> <a
HREF="/cgi-bin/odb-get.exe?WIT_template=temp1"><img src="/metaimagem/gifs/reinic.bmp" WIDTH="84"
HEIGHT="32" border="0" alt="Reinicializa o Resultado de Todas as Consultas" width="84"
height="32"></a></p>
<hr>
<p align="center"><a href="/cgi-bin/odb-logout.exe?WIT_html=/metaimagem/html/inicial.html"
target="_top"><img src="/metaimagem/gifs/exits.bmp" WIDTH="31" HEIGHT="31" border="0" alt="Sair" width="84"
height="30"></a> </p>
</body>
</html>
•
obj_img.html
<html>
<head>
</head>
<body>
<h2 ALIGN="CENTER"><font color="#0000FF">Objeto Imagem</font></h2>
<form action="/cgi-bin/odb-get.exe" method="POST">
<input type="hidden" name="WIT_template" value="objimg-inter"><p>Título:   
   <input TYPE="text"
NAME="titulo" value SIZE="20" MAXLENGTH="20">  </p>
<p>Fonte:       <input TYPE="text" NAME="fonte" value SIZE="30" MAXLENGTH="30">  </p>
<p>Formato:   <input TYPE="text"
NAME="formato" value SIZE="10" MAXLENGTH="10">  </p>
<p>Esquema de compressão:   <input TYPE="text" NAME="esquema" value SIZE="30" MAXLENGTH="30">  </p>
<p>Dimensão do arquivo:       <input TYPE="text" NAME="dimensao" value SIZE="20" MAXLENGTH="20">  </p>
<p>Dimensão da imagem digital:       <input TYPE="text" NAME="dimendig" value SIZE="20" MAXLENGTH="20">  </p>
<p>Resolução:       <input TYPE="text" NAME="resolucao" value SIZE="30" MAXLENGTH="30">  </p>
<p>Localização física:       <input TYPE="text" NAME="localiza" value SIZE="40" MAXLENGTH="40">  </p>
<p>Dispositivo de armazenamento:       <input TYPE="text" NAME="dispositivo" value SIZE="10" MAXLENGTH="10">  </p>
<p>Lugar do repositório:       <input TYPE="text" NAME="repositorio" value SIZE="30" MAXLENGTH="30">  </p>
<p>Direitos autorais:       <input TYPE="text" NAME="direitos" value SIZE="30" MAXLENGTH="30">  </p>
<p>Proprietário:       <input TYPE="text" NAME="proprietario" value SIZE="30" MAXLENGTH="30">  </p>
<p>Digitalizador:       <input TYPE="text" NAME="digitalizador" value SIZE="30" MAXLENGTH="30">  </p>
<p>Tipo de Digitalizador:       <input TYPE="text" NAME="tdigitalizador" value SIZE="30" MAXLENGTH="30">  </p>
<p>Data da criação:       <input TYPE="text" NAME="criacao" value SIZE="10" MAXLENGTH="10">  </p>
<p>Software usado para criação:       <input TYPE="text" NAME="soft" value SIZE="30" MAXLENGTH="30">  </p>
<p>Espaço de cor:       <input TYPE="text" NAME="espaco" value SIZE="15" MAXLENGTH="15">  </p>
<p>Cromia:       <input TYPE="text" NAME="cromia" value SIZE="20" MAXLENGTH="20">  </p>
<div align="center"><center><p><input type="submit" value="Consultar">
<input type="reset" value="Limpar"> </p>
</center></div>
</form>
<hr width="80%" color="#800000">
<a HREF="/cgi-bin/odb-get.exe?WIT_template=opcoes">
<p align="center"><img src="/metaimagem/gifs/volta.gif" WIDTH="31" HEIGHT="31" border="0" alt="Voltar" to main
page] width="84" height="30"></a> <a
href="/cgi-bin/odb-logout.exe?WIT_html=/metaimagem/html/inicial.html" target="_top"><img
<hr width="80%" color="#800000">
</body>
</html>
•
objimg-inter.html
<html>
<body>
<head>
</head>
118
<!DO "defaultCF metaimagemCF">
<!VAR "Bag<Objeto_Imagem>" "botec">
<!VAR "Objeto_Imagem" "oi">
<!VAR "Bag<Objeto_Imagem>" "bodimen">
<!VAR "Bag<Objeto_Imagem>" "borfim">
<!VAR String titulo1>
<!VAR String fonte1>
<!VAR String formato1>
<!VAR String esquema1>
<!VAR String resolucao1>
<!VAR String localiza1>
<!VAR String dispositivo1>
<!VAR String repositorio1>
<!VAR String direitos1>
<!VAR String proprietario1>
<!VAR String digitalizador1>
<!VAR String tdigitalizador1>
<!VAR String soft1>
<!VAR String espaco1>
<!VAR String cromia1>
<!VAR String criacao1>
<!VAR String dimensao1>
<!VAR String dimendig1>
<!VAR Integer auxtec>
<!VAR Integer auxdimen>
<!VAR Integer n>
<!VAR Integer escolhido>
<!DO "botec = Bag{}">
<!DO "wit_botec = Bag{}">
<!DO "bodimen = Bag{}">
<!DO "borfim = Bag{}">
<!DO "titulo1 = wit_titulo">
<!DO "fonte1 = wit_fonte">
<!DO "formato1 = wit_formato">
<!DO "esquema1 = wit_esquema">
<!DO "resolucao1 = wit_resolucao">
<!DO "localiza1 = wit_localiza">
<!DO "dispositivo1 = wit_dispositivo">
<!DO "repositorio1 = wit_repositorio">
<!DO "direitos1 = wit_direitos">
<!DO "proprietario1 = wit_proprietario">
<!DO "digitalizador1 = wit_digitalizador">
<!DO "tdigitalizador1 = wit_tdigitalizador">
<!DO "soft1 = wit_soft">
<!DO "espaco1 = wit_espaco">
<!DO "cromia1 = wit_cromia">
<!DO "criacao1 = wit_criacao">
<!DO "dimensao1 = wit_dimensao">
<!DO "dimendig1 = wit_dimendig">
<!DO "auxtec = 0">
<!DO "auxdimen = 0">
<!DO "wit_oi = List{}">
<!IF "titulo1!="" or fonte1!="" or formato1!="" or esquema1!="" or resolucao1!="" or localiza1!="" or dispositivo1!="" or repositorio1!=""
or direitos1!="" or proprietario1!="" or digitalizador1!="" or tdigitalizador1!="" or criacao1!="" or soft1!="" or espaco1!="" or
cromia1!=""">
<!DO "auxtec = 1">
<!DO "botec = Objeto_Imagem.ConsultaInftec(titulo1, fonte1, formato1, esquema1, resolucao1, localiza1, dispositivo1, repositorio1,
direitos1, proprietario1, digitalizador1, tdigitalizador1, criacao1, soft1, espaco1, cromia1)">
<!DO "borfim = botec">
<!/IF>
<!IF "dimensao1!="" or dimendig1!=""">
<!DO "auxdimen = 1">
<!DO "bodimen = Objeto_Imagem.ConsultaDim(dimensao1, dimendig1)">
<!/IF>
<!IF "auxtec == 1 and auxdimen == 1">
<!DO "borfim = Objeto_Imagem.ConsultaInter(bodimen,botec)">
<!/IF>
<!IF "auxtec == 0 and auxdimen == 1">
119
<!DO "borfim = bodimen">
<!/IF>
<!DO "wit_botec = borfim.unique()">
<!DO "wit_cbotec = 1">
<h2 ALIGN="CENTER"><font color="#0000FF">Objeto Imagem</font></h2>
<a HREF="/cgi-bin/odb-get.exe?WIT_template=resultobjimg&wit_botec">
<p align="center"><img src="/metaimagem/gifs/verimg.bmp" WIDTH="84" HEIGHT="32" border="0" alt="Ver as imagens resposta dessa
consulta">
</a></p>
<p align="center"><img src="/metaimagem/gifs/contcon.bmp" WIDTH="84" HEIGHT="32" border="0" alt="Continuar a consulta"> </a>
</p>
<hr width="80%" color="#800000">
<hr width="80%" color="#800000">
</body>
</html>
•
resultobjimg.html
<html>
<body>
<head>
</head>
<!VAR "Bag<Objeto_Imagem>" "borfim">
<!VAR "Objeto_Imagem" "oi">
<!VAR Integer n>
<!VAR Integer escolhido>
<!DO "botec = Bag{}">
<!DO "n = 0">
<!DO "escolhido = 0">
<!DO "wit_oi = List{}">
<!DO "borfim = wit_botec">
<!FOREACH borfim oi>
<img SRC=<!MEDIA oi.arquivo_imagem_digital image/jpg> WIDTH="150" HEIGHT="150" BORDER=0>
<!DO "wit_oi.insertElementAt(oi, n)">
<a HREF=/cgi-bin/odb-get.exe?WIT_template=resultversoes&wit_oi&escolhido=<!REPLACE n> target=_top>
<img src=/metaimagem/gifs/versao.bmp WIDTH="31" HEIGHT="31" border="0" alt="Versões da imagem anterior"></a>
<a HREF=/cgi-bin/odb-get.exe?WIT_template=resultassoc-escolhido&wit_oi&escolhido=<!REPLACE n> target=_top>
<img src=/metaimagem/gifs/assoc.bmp WIDTH="45" HEIGHT="31" border="0" alt="Imagens Associadas a imagem anterior"></a>
<!DO "n = n+1">
<!/FOREACH>
<hr width="80%" color="#800000">
<hr width="80%" color="#800000">
</body>
120
</html>
•
resultversoes.html
<HTML>
<HEAD>
<TITLE>Tese de Mestrado - IME - Aluna: Simone de Souza Garcia</TITLE>
</HEAD>
<BODY>
<!VAR "List<Objeto_Imagem>" "loversoes">
<!VAR "Objeto_Imagem" "obj">
<!VAR "Integer" "auxescolhido">
<!VAR "String" "auxesco">
<!DO "loversoes = List{}">
<!DO "auxesco = wit_escolhido">
<!DO "auxescolhido = Objeto_Imagem.Converte(auxesco)">
<!DO "obj = wit_oi.getElementAt(auxescolhido)">
<!DO "loversoes = obj.versoes">
<!FOREACH loversoes obj>
<IMG SRC=<!MEDIA obj.arquivo_imagem_digital image/jpg> WIDTH="150" HEIGHT="150" BORDER=0>
<!/FOREACH>
<hr width="80%" color="#800000">
<hr width="80%" color="#800000">
</BODY>
</HTML>
•
resultassoc-escolhido.html
<HTML>
<HEAD>
<TITLE>Tese de Mestrado - IME - Aluna: Simone de Souza Garcia</TITLE>
</HEAD>
<BODY>
<!VAR "List<Tipo_de_Associacao>" "loassocs">
<!VAR "Tipo_de_Associacao" "objtp">
<!VAR "Objeto_Imagem" "obj">
<!VAR "Objeto_Imagem" "objaux">
<!VAR "List<Objeto_Imagem>" "loassociados">
<!VAR "Integer" "auxescolhido">
<!VAR "String" "auxesco">
<!DO "loassocs = List{}">
<!DO "loassociados = List{}">
<!DO "auxesco = wit_escolhido">
<!DO "auxescolhido = Objeto_Imagem.Converte(auxesco)">
<!DO "obj = wit_oi.getElementAt(auxescolhido)">
<!DO "loassocs = obj.objetos_associados">
<!FOREACH loassocs objtp>
<!DO "objaux = objtp.objeto_imagem">
<IMG SRC=<!MEDIA objaux.arquivo_imagem_digital image/jpg> WIDTH="150" HEIGHT="150" BORDER=0>
<!Replace objtp.tipo>
<!DO "loassociados = List{}">
<!DO "loassociados = objtp.objetos_associados">
<!FOREACH loassociados obj>
<IMG SRC=<!MEDIA obj.arquivo_imagem_digital image/jpg> WIDTH="150" HEIGHT="150" BORDER=0>
<!/FOREACH>
<hr width="100%" color="#600000">
<!/FOREACH>
121
<hr width="80%" color="#800000">
<hr width="80%" color="#800000">
</BODY>
</HTML>
122
APÊNDICE C
PROCEDIMENTOS PARA UTILIZAÇÃO DO JASMINE
CRIAÇÃO DE STORE E CLASS FAMILY
Antes da criação das classes é necessário que seja alocado um espaço onde serão
armazenadas essas classes, que no Jasmine dá-se o nome de Store. O Jasmine trabalha com
um conceito de Class Family para a criação das classes, significando que, para cada projeto
criado no sistema existirá uma classe família, a partir da qual serão criadas as classes do
esquema conceitual correspondente àquele projeto. Assim sendo, as classes do esquema
contidas em uma Class Family serão armazenadas em um Store.
Passos para a criação de Store e Class Family, considerando-se que o Jasmine esteja
instalado no drive C:
•
Para se criar um Store: na linha de comando DOS entrar no diretorio
c:\jasmine\jasmine\bin e com o Jasmine em execução executar o seguinte comando:
createStore metaimagem c:\jasmine\metaimagem
Sendo metaimagem o nome do Store criado.
•
Para se criar uma Class Family (classe família): na linha de comando DOS entrar no
diretorio c:\jasmine\jasmine\bin e com o Jasmine em execução executar o seguinte
comando:
createCF metaimagemCF metaimagem
Sendo metaimagemCF o nome da Class Family criada dentro do Store metaimagem.
Após a criação de um Store e uma Class Family, pode-se então iniciar a etapa de
criação das classes e métodos de um projeto.
123
CÓPIA E RECUPERAÇÃO DO BANCO DE DADOS
Após ter sido criado um projeto no Jasmine é importante saber como fazer a cópia e a
recuperação do banco de dados, contendo todas as classes, métodos e objetos instanciados
pertencentes a uma class family, considerando que o Jasmine está instalado no drive C:
•
Para copiar o banco de dados para disquete: na linha de comando DOS entrar no diretório
c:\jasmine\jasmine\bin e executar o comando abaixo: (obs: o Jasmine não pode estar em
execução)
unload -o a:\metacopia metaimagemCF
Sendo metacopia o nome dado à cópia feita da class family metaimagemCF.
•
Para copiar do disquete para o banco de dados: na linha de comando DOS entrar no
diretório c:\jasmine\jasmine\bin e executar o comando abaixo: (obs: o Jasmine não pode
estar em execução)
load a:\metacopia -s -d all -c metaimagemCF=metaimagemCF
•
No caso de classes que possuam propriedades do tipo multimídia faz-se necessária a cópia
da class family MEDIACF1 (classe já existente no Jasmine), pois os dados do tipo
multimídia (imagens, vídeos, sons e documentos) são armazenados nesta classe chamada
MEDIACF1, estando somente os ponteiros referentes a esses dados armazenados na
classe a qual a propriedade pertence de fato. Nesse caso é necessário que seja feita a cópia
da class family MEDIACF1 além da class family do projeto.
unload -o a:\mediacopia mediaCF1
e para a recuperação da MEDIACF1 de volta ao banco de dados:
load a:\mediacopia -s -d all -c mediaCF1=mediaCF1
Sendo mediacopia o nome dado à cópia da classe MEDIACF1.
124
CONFIGURAÇÃO DO WEBLINK
Essa seção descreve passo a passo os procedimentos necessários para configurar o
ambiente para a utilização do WebLink em Windows NT:
•
Instalar o servidor de Internet:
Entrar em :
Meu computador
Rede
Adicionar Serviço
Microsoft Internet Information Server
•
Adicionar as linhas abaixo no arquivo SERVICES do diretório Winnt/System32 por meio
do programa Notepad:
Weblinkp
Weblink
Weblinkd
•
10014/tcp
10015/tcp
10016/tcp
Adicionar o diretório weblink\cgi-bin aos diretórios do serviço WWW no programa
Microsoft Internet Server:
Entrar em :
Gerenciador de serviço da internet
diretórios WWW
adicionar weblink\cgi-bin
marcar opção de leitura e execução
reiniciar servidor (clicar no botão parar serviço e depois iniciar
serviço)
Com o serviço de Internet já instalado, é necessário configurar adequadamente o
WebLink utilizando-se para isso o programa WebLink Environment Editor, mostrado na
Figura C.1, que também vem junto com o Jasmine. A configuração necessária é mostrada
logo após a Figura C.1.
125
FIGURA C.1: Tela do WebLink Environment Editor.
- Server Environment Editor:
maxConnection: (em branco)
serverLog: c:\jasmine\weblink\temp\server.log
numberPublicSessions: 0
serverLogLevel: 0
acsLog: c:\jasmine\weblink\log\acess
errorLog: c:\jasmine\weblink\temp\weblinkerr
acsLogLevel: 2
errorLogLevel: 1
DBName: nome da máquina idle Timeout: 65
DBEnvFile: c:\jasmine\jasmine\envFile\local.env
homePage: (em branco)
logoutPage: (em branco)
userid: nome do usuário
passwd: senha
- Public Environment Editor:
ascLog: c:\jasmine\weblink\temp\PublicAccess.log
ascLogLevel: 0
errorLogLevel: 0
DBName: nome da máquina busy Timeout: 64
passwd: senha
- Default
acsLog: c:\jasmine\weblink\temp\PublicAccess.log
126
acsLogLevel: 0
errorLogLevel: 0
homePage: file://e:\InetPub\wwwroot\demo\html\home.html
logoutPage: (em branco)
paswd: senha
- Application Environment Editor (metaimagem):
acsLog: c:\jasmine\weblink\temp\acslog.log
acsLogLevel: 0
errorLogLevel: 0
homePage: file://c:\metaimagem\html\home.html
logoutPage: file://c:\metaimagem\html\home.html
userid: (em branco)
passwd: (em branco)
127
APÊNDICE D
UTILIZAÇÃO DO ESQUEMA EM XML
XML (Extensible Markup Language) (LIGHT, 1999) é a tecnologia recente, utilizada
na Internet, com tendência a se tornar padrão com o objetivo de indexar, representar,
descrever e divulgar recursos no ambiente WWW. Permite criar tags e elementos a partir de
um subconjunto das linguagens anteriores SGML (Standard Generalized Markup Language)
e da HTML (HyperText Markup Language).
Tags XML provêem informação sobre o conteúdo ali contidos (CLARK, 1998). Como
vantagens da XML (XML) podem ser citadas as seguintes: baseia-se em padrões
internacionais existentes; é totalmente extensível, sem limitações de tags (etiquetas); pode
modelar qualquer tipo de dado; suporta controle de validação e editoração; gera
automaticamente ligações e auxílios navegacionais; permite gerar visões configuráveis pelo
usuário dinamicamente; apresenta sistema de administração mais simples de sites Web;
permite fácil redefinição de documentos; apresenta maior velocidade de acesso aos dados.
Em consonância com a relevância da XML no contexto atual de desenvolvimento de
recursos em ambientes distribuídos tal como WWW, é importante situar como o presente
esquema poderia ser desenvolvido no contexto da XML.
Esse apêndice mostra as vantagens da XML e a possível ligação dessa nova tecnologia
com o esquema para documentação e recuperação de imagens, proposto no Capítulo 4.
CARACTERÍSTICAS DA XML
XML agrupa os dados entre tags similares aos usados em HTML, com a diferença de
que em XML podem ser criados novos tags, usados para definirem os dados nele contidos.
Em XML (CLARK, 1998) o termo “element” é usado para descrever os tags (ambos tags de
128
inicialização e finalização). Como por exemplo, a definição do elemento TOPIC seria:
<TOPIC> O tópico do artigo é XML</TOPIC>.
Quando servidores Web preparam a transmissão de dados com conteúdo XML,
tipicamente devem incluir ponteiros para a DTD (Document Type Definition) associada.
Clientes Web que processam XML devem ser capazes de analisar o contexto de acordo com a
DTD e de interpretar a semântica do hipertexto associada a cada um dos diferentes tags do
documento (KHARE & RIFKIN, 1997).
A DTD permite validar o conjunto de tags para o próprio uso da aplicação. Especifica
o conjunto de elementos requeridos e opcionais para os documentos de acordo com o tipo,
definindo ainda o nome dos tags e o relacionamento entre elementos em um documento,
como por exemplo, o aninhamento dos elementos. A DTD indica ao software como lidar com
o documento XML, funcionando como a definição dos tipos dos tags criados.
EXEMPLO EM XML
O exemplo a seguir apresenta as classes Objeto_Imagem, Conteudo_Semantico e
Componente, na descrição de duas imagens (Paisagem Natural e Foto de Ballet), do esquema
desenvolvido nesse trabalho; segundo a sintaxe da XML.
<XML>
<?XML VERSION = “1.0” ?>
<!DOCTYPE METAIMAGEM SYSTEM “metaimagem.dtd”>
<OBJETO_IMAGEM>
<TITULO> Paisagem Natural </TITULO>
<FORMATO> JPG </FORMATO>
<ESQUEMA_COMPRESSAO> LZW </ ESQUEMA_COMPRESSAO>
<DIMENSAO_ARQUIVO> 10 KB </ DIMENSAO_ARQUIVO>
<DIMENSAO_IMAGEM_DIGITAL> 10x15 cm </ DIMENSAO_IMAGEM_DIGITAL>
<RESOLUCAO> 640x480 </RESOLUCAO>
<LOCALIZACAO_FISICA>http://200.20.120.181/metaimagem/pan.jpg</LOCALIZACAO_FISICA>
<DISPOSITIVO_ARMAZENAMENTO> disco rígido </DISPOSITIVO_ARMAZENAMENTO>
<LUGAR_REPOSITORIO> Rio de Janeiro </LUGAR_REPOSITORIO>
<DIREITOS_AUTORAIS> </DIREITOS_AUTORAIS>
<PROPRIETARIO> Pedro </PROPRIETARIO>
<DIGITALIZADOR> Pedro <DIGITALIZADOR>
<TIPO_DIGITALIZADOR> Scanner HP </TIPO_DIGITALIZADOR>
<DATA_CRIACAO> 05/01/1999 </DATA_CRIACAO>
<SOFTWARE_USADO_CRIACAO> </SOFTWARE_USADO_CRIACAO>
129
<ESPACO_COR> RGB </ESPACO_COR>
<CROMIA> colorida </CROMIA>
<CONTEUDO_SEMANTICO>
<NOME> Espaco </NOME>
<DESCRICAO_GENERICA> Praia de Fortaleza </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Praia das Dunas </DESCRICAO_ESPECIFICA>
<SOBRE> Paraíso </SOBRE>
<NOME> Ação </NOME>
<DESCRICAO_GENERICA> Por do sol </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Por do sol na praia </DESCRICAO_ESPECIFICA>
<SOBRE> Felicidade </SOBRE>
<COMPONENTE>
<NOME> Componente </NOME>
<DESCRICAO_GENERICA> Árvore </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Coqueiro </DESCRICAO_ESPECIFICA>
<SOBRE> </SOBRE>
<DESCRICAO_GENERICA> Sol </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Sol na praia </DESCRICAO_ESPECIFICA>
<SOBRE> </SOBRE>
<DESCRICAO_GENERICA> Mar </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Praia das Dunas </DESCRICAO_ESPECIFICA>
<SOBRE> </SOBRE>
</COMPONENTE>
</CONTEUDO_SEMANTICO>
</OBJETO_IMAGEM>
<OBJETO_IMAGEM>
<TITULO> Foto de Ballet </TITULO>
<FORMATO> JPG </FORMATO>
<ESQUEMA_COMPRESSAO > LZW </ ESQUEMA_COMPRESSAO >
<DIMENSAO_ARQUIVO > 9 KB </ DIMENSAO_ARQUIVO >
<DIMENSAO_IMAGEM_DIGITAL > 10x15 cm </DIMENSAO_IMAGEM_DIGITAL >
<RESOLUCAO> 640x480 </RESOLUCAO>
<LOCALIZACAO_FISICA> http://200.20.120.181/metaimagem/bal.jpg</LOCALIZACAO_FISICA>
<DISPOSITIVO_ARMAZENAMENTO> disco rígido </DISPOSITIVO_ARMAZENAMENTO>
<LUGAR_REPOSITORIO> Rio de Janeiro </LUGAR_REPOSITORIO>
<DIREITOS_AUTORAIS> </DIREITOS_AUTORAIS>
<PROPRIETARIO> Pedro </PROPRIETARIO>
<DIGITALIZADOR> Pedro <DIGITALIZADOR>
<TIPO_DIGITALIZADOR> Scanner HP </TIPO_DIGITALIZADOR>
<DATA_CRIACAO> 06/01/1999 </DATA_CRIACAO>
<SOFTWARE_USADO_CRIACAO> </SOFTWARE_USADO_CRIACAO>
<ESPACO_COR> RGB </ESPACO_COR>
<CROMIA> preto e branco </CROMIA>
<CONTEUDO_SEMANTICO>
<NOME> Espaco </NOME>
<DESCRICAO_GENERICA> Teatro Municipal </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Rio de Janeiro </DESCRICAO_ESPECIFICA>
<SOBRE> Espetáculo </SOBRE>
<NOME> Ação </NOME>
<DESCRICAO_GENERICA> Dança </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Dança clássica </DESCRICAO_ESPECIFICA>
<SOBRE> Romantismo </SOBRE>
<COMPONENTE>
<DESCRICAO_GENERICA> Bailarina </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Paloma Herrera </DESCRICAO_ESPECIFICA>
<SOBRE> </SOBRE>
<DESCRICAO_GENERICA> Bailarino </DESCRICAO_GENERICA>
<DESCRICAO_ESPECIFICA> Angel Corella </DESCRICAO_ESPECIFICA>
<SOBRE> </SOBRE>
</COMPONENTE>
</CONTEUDO_SEMANTICO>
</OBJETO IMAGEM>
<XML>
130
metaimagem.dtd
<!DOCTYPE METAIMAGEM>
<!ELEMENT OBJETO_IMAGEM (TITULO, FONTE, ESQUEMA_COMPRESSAO, DIMENSAO_ARQUIVO,
DIMENSAO_IMAGEM_DIGITAL, RESOLUCAO, LOCALIZACAO_FISICA, DISPOSITIVO_ARMAZENAMENTO,
LUGAR_REPOSITORIO, DIREITOS_AUTORAIS, PROPRIETARIO, DIGITALIZADOR, TIPO_DIGITALIZADOR,
DATA_CRIACAO, SOFTWARE_USADO_CRIACAO, ESPACO_COR, CROMIA, CONTEUDO_SEMANTICO +)>
<!ELEMENT TITULO (#PCDATA)>
<!ELEMENT FONTE (#PCDATA)>
<!ELEMENT ESQUEMA_COMPRESSAO (#PCDATA)>
<!ELEMENT DIMENSAO_ARQUIVO (#PCDATA)>
<!ELEMENT DIMENSAO_IMAGEM_DIGITAL (#PCDATA)>
<!ELEMENT RESOLUCAO (#PCDATA)>
<!ELEMENT LOCALIZACAO_FISICA (#PCDATA)>
<!ELEMENT DISPOSITIVO_ARMAZENAMENTO (#PCDATA)>
<!ELEMENT LUGAR_REPOSITORIO (#PCDATA)>
<!ELEMENT DIREITOS_AUTORAIS (#PCDATA)>
<!ELEMENT PROPRIETARIO (#PCDATA)>
<!ELEMENT DIGITALIZADOR (#PCDATA)>
<!ELEMENT TIPO_DIGITALIZADOR (#PCDATA)>
<!ELEMENT DATA_CRIACAO (#PCDATA)>
<!ELEMENT SOFTWARE_USADO_CRIACAO (#PCDATA)>
<!ELEMENT ESPACO_COR (#PCDATA)>
<!ELEMENT CROMIA (#PCDATA)>
<!ATTLIST CONTEUDO_SEMANTICO (NOME, DESCRICAO_GENERICA, DESCRICAO_ESPECIFICA, SOBRE,
COMPONENTE +)>
<!ELEMENT NOME (#PCDATA)>
<!ELEMENT DESCRICAO_GENERICA (#PCDATA)>
<!ELEMENT DESCRICAO_ESPECIFICA (#PCDATA)>
<!ELEMENT SOBRE (#PCDATA)>
<!ATTLIST COMPONENTE (NOME, DESCRICAO_GENERICA, DESCRICAO_ESPECIFICA, SOBRE)>
Vale a pena observar alguns pontos com relação a sintaxe de definição de DTD em XML:
•
O caracter “+” indica que o elemento que o precede ocorre uma ou mais vezes;
•
A identificação #PCDATA identifica dados do tipo caracter;
•
ATTLIST define um elemento do tipo lista.
CONSIDERAÇÕES FINAIS DESSE APÊNDICE
Documentos XML são formados por dados e marcações (markup), que podem ser
consideradas como metadados, representados nesta linguagem por tags.
Para que a XML seja utilizada no âmbito do esquema desenvolvido nesse trabalho,
faz-se necessário a prévia identificação e definição dos tags a serem criados. O esquema
proposto no Capítulo 4 foi portanto um pré-requisito básico para a utilização dessa linguagem
na descrição de imagens, pois na verdade todas as classes e propriedades identificadas no
131
esquema constituem os tags para a criação desse padrão em XML. A descrição desse esquema
em XML possibilita portanto a sua disponibilização na Internet como um padrão para a
documentação de imagens. No entanto, para que as imagens descritas em XML possam ser
armazenadas, é necessária a sua veiculação a um SGBD e ainda a necessidade de uma
aplicação que entenda a DTD definida para obtenção das informações ali definidas. Sabe-se
que os SGBDs atualmente incluem componentes para ligação com Internet, mas segundo
(LIGHT, 1999) a XML não se preocupou ainda em tratar a conexão com banco de dados, essa
tarefa está sendo tratada pela HTML.
132
REFERÊNCIAS BIBLIOGRÁFICAS
AMORE – http://titian/neclab.com/amore/index.html, 1998.
BESSER, Howard & TRANT, Jennifer - “Introduction to Imaging: Issues in Constructing an
Image Database” - http://www.ahip.getty.edu/intro_imaging/Tb1.html, 1995.
BOUTELL, T., et alii. - “PNG (Portable Network Graphics) Specification Version 1.0” ftp://ds.internic.net/rfc/rfc2083.txt, março 1997.
BROSS, V. - “Webliography: Meta Data, Meta Tags, and the Dublin Core” http://www.web-action.com/webography.html, abril 1997.
BURNARD,
Lou
-
“The
Text
Encoding
Initiative
Guidelines”
-
ftp:info.ox.ac.uk/publota/TEI/doc/teij31.sgml, 1994.
CAETANO, Artur et alii. – “A Description Model for Multimedia Content” – Instituto
Superior Técnico, Universidade de Lisboa, 1998.
CAI – http://www.cai.com, 1998.
CHANG, S. et alii. - “Visual Information Retrieval From Large Distributed Online
Repositories” - Communications of The ACM, Vol. 40, No. 12, dezembro 1997.
CHANG, Wendy & ZHANG, Aidong – “Metadata for Distributed Visual Database Access” –
Second
IEEE
Metadata
Conference,
Silver
Spring,
Maryland,
http://computer.org/conferen/proceed/meta97/papers/azhang/ azhang.html, setembro
1997.
CLARK,
Scott
-
“The
WebDeveloper.com
Guide
to
XML”
–
http://www.webdeveloper.com/categories/html/html_xml_1.html, 1998.
CORDEIRO, Rosa Inês de Novais – Descrição e Representação de Fotografias de Cenas e
Fotografias de Filmes: Um Esquema de Indexação – Tese de Mestrado, Instituto
Brasileiro de Informação em Ciência e Tecnologia, Universidade Federal do Rio de
Janeiro, 1990.
133
DEMPSEY, Lorcan & WEIBEL, Stuart L. - “The Warwick Metadata Workshop: A
Framework
for
the
Deployment
of
Resource
Description”
-
http://www.ukoln.ac.uk/~lisld/, D-Lib Magazine, 1996.
DEUTSCH, P. et alii. - “Publishing Information on the Internet with Anonymous FTP” http://info.Webcrawler.com/mak/projects/iafa/iafa.txt, 1994.
EXCALIBUR – http://www.excalib.com/demos/demos.html.
FGDC – Content Standard for Digital Geospacial Metadata, Federal Geographic Data
Committee–http://geochange.er.usgs.gov/pub/tools/metadata/standard/metadata.html.
FLICKNER, M. et alii. - “Query by Image and Video Content: The QBIC System” - IEEE
Computer Vol. 28 No 9, setembro 1995.
FOLEY, James et alii – “Computer Graphics: Principles and Practice”, Addison-Wesley
Publishing Company, 1990.
FUNARTE – Manual Para Catalogação de Documentos Fotográficos, 2.ed., Ministério da
Cultura, FUNARTE, 1998.
FURLAN, José Davi – Modelagem de Objetos Através da UML: the Unified Modeling
Language, Makron Books, São Paulo, 1998.
GEMINI – http://www.gemini.art.br, 1998.
GROSKY, W. - “Managing Multimedia Information in Database Systems” - Communications
of The ACM, Vol. 40, No. 12, dezembro 1997.
GROSKY, W. et alii. - “Research Directions in Image Database Management” - IEEE 8th
International Conference on Data Engineering, 1992.
GUHA,
R.
&
BRAY,
T.
-
“Meta
Content
Framework
Using
XML”
-
http://www.w3.org/TR/NOTE-MCF-XML-970606, 1997.
GUPTA,
A.
–
“Visual
Information
Retrieval:
http://www.virage.com/wpaper, 1997.
134
A
Virage
Perspective”
–
GUPTA, A. et alii - “Semantic Queries with Pictures: The VIMSYS Model” - Proceedings of
the 17th International Conference on Very Large Data Bases, Barcelona, Espanha,
setembro 1991.
HEERY, Rachel – “Review of Metadata Formats” – Program vol 30, Issue no 4, 1996.
HEERY,
Rachel
et
alii.
–
4th
“The
Dublin
Core
Workshop”-
http://www.ukoln.ac.uk/metadata/resources/dc4-notes.html, março 1997.
HERMES,
Th.
et
alii.
-
"Image
Retrieval
for
Information
Systems”
-
http://www.informatik.uni-bremen.de/grp/ag-ki/papers/pub-papers/thSpiepaper95.ps,
Proceedings of IS&T/SPIE’s Symposium on Electronic Imaging: Science &
Technology, San Jose, CA, USA, fevereiro 1995.
JAIN, Anil K. & DORAI, Chitra – “Practicing Vision: Integration, Evaluation and
Aplications” – Pattern Recognition, vol. 30, n.2, pags. 183-196, 1997.
JAIN, R. & GUPTA, A. - "Computer Vision and Visual Information Retrieval” http://vision.ucsd.edu/papers/rosenfeld/rosen3.html, 1996.
KERHERVÉ, Brigitte - “Models for Metadata or Metamodels for Data?” - Second IEEE
Metadata
Conference,
Silver
Spring,
Maryland,
http://computer.org/conferen/proceed/meta97/papers/bkerherve/bkerherve.html,
setembro 1997.
KHARE, Rohit & RIFKIN, Adam – “X Marks the Spot: Using XML to Automate the Web”,
IEEE
Internet
Computing,
vol.
1,
n.
4,
pg.
78-87,
july/august
1997.
http://www.cs.caltech.edu/~adam/papers/xml/x-marks-the-spot.html.
KHOSHAFIAN, S. & BAKER, A. Brad - “Multimedia and Imaging Databases” - Morgan
Kaufmann Publishers, 1996.
KHOSHAFIAN, Setrag et alii. – “The Jasmine Object Database: Multimedia Applications for
the Web”, Morgan Kaufmann Publishers, 1998.
135
LAGOZE,
Carl
&
DANIEL,
Ron
-
“Extending
the
Warwick
Framework”,
D-Lib
Magazine,
http://www.dlib.org/dlib/november97/daniel/11daniel.html,
novembro 1997.
LASSILA, Ora & SWICK, Ralph R. - “Resource Description Framework (RDF) Model and
Syntax” - http://www.w3.org/TR/WD-rdf-syntax/index.html, 1997.
LIGHT, Richard – Iniciando em XML, Makron Books, 1999.
LORENZ, O. Christoph - "Retrieval by Graphic Content” – http://www-ir.inf.ethz.ch/PublicWeb-Pages/lorenz/it/node6.html, 1997.
MEYER, Wladimir - Metodologias para Classificação de Texturas e Consulta a Bases de
Imagens - Tese de Mestrado, Instituto Militar de Engenharia (IME), 1997.
MILLER,
Eric
J.
–
“CNI/OCLC
Metadata
Workshop”
–
http://www.oclc.org:5046/conferences/imagemeta/, setembro 1996.
MNG - ftp://swrinde.nde.swri.edu/pub/mng/documents/MNG_status_19970122.html, 1997.
MOURA, Ana Maria C. , CAMPOS, Maria Luíza M., BARRETO, Cassia M. - “Metadata
Support for Describing and Retrieving Internet Resources”- Submetido ao WWW
Journal, 1998.
MURRAY, James D. - "SPIFF: Still Picture Interchange File Format” - Dr. Dobb’s Journal,
julho 1996.
MURRAY, James D. & VANRYPER, W. - "Encyclopedia of Graphics File Formats” - 2a
edição, O’Reilly & Assoc., 1996.
ORIA, Vincent et alii. – “Modeling Images for Content-Based Queries: The DISIMA
approach” – Second International Conference on Visual Information Systems, San
Diego,
CA,
pg.
339-346,
http://web.cs.ualberta.ca/~database/research/multimedia/publications.html, dezembro
1997.
136
PANOFSKY, E. – Significado nas Artes Visuais – 2.ed. São Paulo: Perspectiva, 1979.
(Debates, 99).
PNG
-
“Things
that
go
PNG
on
the
Web”
-
http://www.cs.man.ac.uk/aig/staff/toby/writing/png.htm, Personal Computer World,
1997.
PRABHAKARAN, B. – “Multimedia Database Management Systems” , Kluwer Academic
Publishers, 1997.
QBIC - “QBIC - IBM’s Query By Image Content” - http://wwwqbic.almaden.ibm.com, 1997.
RABITTI, F. & SAVINO, P. - "An Information Retrieval Approach for Image Databases” Proceedings of the 18th VLDB Conference, Vancouver, British Columbia, Canadá
1992.
RICH, Elaine & KNIGHT, Kevin - Inteligência Artificial - 2a edição, Makron Books, São
Paulo, 1993.
ROELOFS, Greg - “PNG´s Not GIF” - http://webreview.com/97/05/09/feature/, 1997a.
ROELOFS, Greg - “Portable Network Graphics” - http://www.wco.com/~png/, 1997.
SAIF - http://epoch.cs.berkeley.edu:8000/sequoia/schema/html/saif/section1.1.html.
SHAH, Kshitij et alii. - “Black Box Approach to Image Feature Manipulation used by Visual
Information Retrieval Engines” - Second IEEE Metadata Conference, Silver Spring,
Maryland,
http://computer.org/conferen/proceed/meta97/papers/kshah/kshah.html,
setembro 1997.
SHATFORD, Sara – “Analyzing the Subject of a Picture: A Theoretical Approach” –
Cataloging & Classification Quarterly, v. 6, n. 3, p. 39-62, 1986.
SHKLAR, Leon et alii. – “InfoHarness: Use of Automatic Generated Metadata for Search and
Retrieval
of
Heterogeneous
Information”
http://www.lsdis.cs.uga.edu/publications/pub_ALL.html, 1994.
137
–
SMIT, Johanna W. – A Análise da Imagem: Um Primeiro Plano – In: ___. (Coord.). Análise
Documentária: a análise da síntese. Brasília: IBICT, p. 99-111, 1987.
SMIT, Johanna W. – A Representação da Imagem – INFORMARE – Cadernos do Programa
de Pós-Graduação em Ciência da Informação, Rio de Janeiro, v.2, n.2, p.28-36,
jul./dez. 1996.
SPIFF
-
“GFF
Format
Summary:
SPIFF”
-
http://www.ipahome.com/gff/textonly/summary/spiff.htm, 1995.
VIRAGE – http://www.virage.com/market/vir-body.html, 1998.
WEIBEL, Stuart – “A Proposed Convention for Embedding Metadata in HTML” –
http://www.oclc.org:5046/~weibel/html-meta.html, junho 1996.
WEIBEL,
Stuart
et
alii.
–
“OCLC/NCSA
Metadata
Workshop
Report”-
http://www.oclc.org:5046/oclc/research/conferences/metadata/dublin_core_report.ht
ml, março 1995.
XML - “XML: Overview” - http://sunsite.unc.edu/pub/sun-info/standards/xml/pres/9797ja/sld02000.htm.
138

instituto militar de engenharia metadados para - SE/8

Transcrição

Documentos relacionados

Quotas de Associação - Camara de Comercio Colombo Brasilera

Jornal Record - Wrestling Portugal

2008-1001_O Lugar das Pessoas

t2 em condomínio com piscina, a 5 minutos a pé da marina da

The Role of Business Intelligence in Compliance at the

Efeito Joule

metadados como infra-estrutura

Como utilizar HTML nos seus anúncios do MercadoLivre

Documentos digitais e novas formas de cooperação entre sistemas

¢¡¤£¦¥ §¢¨¦©