Gestão e Recuperação
de Informação
Metadados...
José Borbinha – DEI/IST
Aviso Prévio
• O contexto de uso do termo “metadata/metadados”
aqui usado não é o mesmo que é usado em (embora
numa perspectiva genérica tudo isto não seja assim
tão diferente...):
– Bases de dados / Data Warehouse
• Catálogo, ...
– Arquitectura Empresarial
• CMDB - Configuration Management Database (conceito
ITIL...), ...
– ...
2
O que é então “metadata” no
contexto de RGI?
• O nosso contexto vai ser o da “informação documental”!
Isto é considerando que:
– “metadata” refere-se a “dados sobre dados”...
– os nossos objectos de informação são documentos
• Então no nosso contexto “metadata” dirá respeito a “dados
sobre documentos”...
•
Desabafo: isto dito assim até pode parecer claro, mas não será assim tanto... na realidade
as fronteiras entre todas as aplicações do termo acabam mesmo por se fundir! Mas isso
será uma perspectiva mais avançada disto tudo!
3
“Documento”?
• Um documento é um contentor de informação organizada para ser
disponibilizada sob uma dada forma!
• Referências:
– Document engineering is the computer science discipline that
investigates systems for documents in any form and in all media. As
with the relationship between software engineering and software,
document engineering is concerned with principles, tools and
processes that improve our ability to create, manage, and maintain
documents. (http://www.documentengineering.org/)
– A document is an abstract container that stores information. It may be
generated statically or dynamically, it may be transient or persistent,
its encoding may be time variant.
(http://www.icmc.usp.br/~doceng08/cfp.html)
4
Porque é o conceito de “metadata”
relevante no contexto de RGI?
• Já vimos técnicas básicas de identificar, recuperar/ ou
recolher objectos de informação a partir apenas dos seus
conteúdos! Esses métodos são no entanto inúteis quando:
– Não é possível, tecnicamente, extrair automaticamente dos objectos
qualquer informação (Ex.: um livro impresso, uma pintura, uma
escultura, ...)
– O objecto é acessível, mas a informação necessária para suportar a
pesquisa não existe simplesmente no objecto (Ex.: objectos criados
por uma dada pessoa a qual não refere explicitamente nos mesmos
ser a sua autora...)
– Os conteúdos dos objectos são gerados dinamicamente, sendo
impossível prevê-los (Ex.: um programa de rádio ou televisão a
emitir ao vivo, ...)
– ...
5
Porque é o conceito de “metadata”
relevante no contexto de RGI?
• “Metadados representam assim os objectos!!!
• Se for informação estruturada, “metadados” podem
representar os objectos na descrição:
– do seu conteúdo...
• (indexação -por palavras-chave, ...-, classificação, ...)
– da sua estrutura...
• (esquema ou formato, tamanho...)
– da sua autoria/proveniência/responsabilidade...
• (autor, data de criação, curador, ...)
– das suas condições de utilização...
• (autorização necessária para acesso, preço, ...)
– ...
6
Porque é o conceito de “metadata”
relevante no contexto de RGI?
• Concluindo, tendo metadados relativos a um objecto
podemos usar esses metadados em cenários de recuperação
de informação sem necessidade de recorrer ao objecto!
Interface
?
?
?
?
Metadata
?
Interface
?
7
Porque é o conceito de “metadata”
relevante no contexto de RGI?
• Mas já agora, existindo as duas coisas, porque não usá-las
(o melhor dos dois mundos)?
Metadata
Interface
8
LOM
METS
Dublin Core
ONIX
ISO 11179
RDF
EAC
LCSH
UNIMARC
UDC
MARC 21
FRBR
XML
MDR
EAD
PREMIS
marcXchange
MPEG
MODS
MADS
AACR2
TEI
DDC
ISO 2709
9
Descrição de objectos
Objectos e sua
estrutura
METS
LOM
TEI
MPEG
Atributos
Dublin Core
PREMIS
MDR
ISO 11179
Bibliotecas
Conceitos
FRBR
Regras de criação
Editores
AACR2
ONIX
UNIMARC
MARC 21
MADS
MODS
Arquivos
EAC EAD
Valores para atributos
UDC LCSH
DDC
Codificação
ISO 2709
XML
RDF marcXchange
...
10
Um mapa conceptual...
11
Reference Models
- AACR
- FRBR
- CIDOC
- MoReq
…
Conceptual
Perspective
Metadata Schemas
- MARC21
- UNIMARC
- DCMES
- ONIX
- METS
- EAD
- EAC
…
Metadata Implementations
- The UNIMARC coding in ISO2709…
- The MARC21 coding in ISO2709…
- MARCXML: MARC coding in XML
- A DCMES Schema coding in XML…
- A DCMES Schema coding in RDF…
-…
Context
Perspective
Service
Perspective
Metadata Structures
- One file: myUNIMARCrecords.iso
- One file: yourMARC21records.iso
- One file: myUNIMARCrecords.xml
- One file: yourMARC21records.xml
- One file: myDCMESrecords.xml
- One file: myDCMESrecords.rdf
-…
Services and Interfaces
- An HTTP/HTML based OPAC service
- An OAI metadata harvesting service
- A Z39.50-Bath search service
- A ZING Web Service
-…
Tecnology
Perspective
File and data
structures
- IS2709
- HTML
- XML
- RDF
…
Protocols
- HTTP
- OAI-PMH
- SOAP
- Z39.50
- WebServices
- ZING
- ...
…
12
Como se define uma norma ou
recomendação?
13
Processos e entidades de normalização
1. Problema bem identificado, partilhado por uma franja alargada
da comunidade, com uma solução a tender para o consensual
(nem sempre, mas...) e preferencialmente não polémico =>
normalização formal, acabando por vezes mesmo em
aprovação por entidades nacionais que tornam os resultados
obrigatórios (Ex.: ISO; normas NP em Portugal, DIN na
Alemanha, ANSI e NISO nos Estados Unidos, etc...)
2. Problema perceptível, de interesse geral, mas ainda à procura
de uma solução que requer o envolvimento da comunidade =>
normalização por entidades “ad hoc” ou especializadas na área
do problema, cujos resultados são por vezes entendidos como
recomendações (Ex.: W3C, IETF, IEEE, ..., OASIS).
3. Problema localizado num dado projecto, organização ou
comunidade restrita => solução definida e testada localmente...
14
Processos e entidades de normalização
1. Normalização formal:
–
–
Processo nem sempre pacífico! Ex.; “Batalha” na ISO da Microsoft para ver o
OOXML aprovado (parte da “guerra”com o ODF - OpenDocument Format...)
Boas normas nacionais acabam por vezes por ver a aprovação internacional
facilitada (Ex. NISO Z39.50 = ISO 23950)
2. Normalização “ad hoc”
–
–
Por vezes, quando estes resultados atingem relevância mais alargada, acabam
por ser levados ao nível anterior (Ex: Dublin Core -> ISO 15836)
Neste contexto os processos tendem a ser mais pacíficos (ver a convergência
conseguida normalmente nos grupo IETF ou W3C) mas também há “casos”,
especialmente quando os interesses financeiros em jogo são relevantes (Ex:
problemas recentes com o processo em torno da IEEE 802.20, reticências sobre
patentes pendentes relacionadas com a MPEG-21, etc...)
3. Problema localizado
–
Por vezes, quando estas soluções resultam e se demonstra terem interesse geral,
acabam por ser propostas aos níveis anteriores...
15
Processos e entidades de normalização
1. Normalização formal
2.
Normalização “ad hoc”
3.
Problema localizado
Visão de negócio,
Requisitos
Percepção da necessidade
com necessidade de
discussão consensual
Prática, Experiência,
Resultados provados
16
Exemplos...
17
urn.porbase.org
Registos bibliográficos e de autoridades em vários esquemas e codificações...
18
“A Morgadinha dos Canaviais”
UNIMARC (texto)
Etiqueta de registo: 00579cam 02200217 04500
001 1535
005 19990421151100.0
095 ## $aPTBN00001574
100 ## $a19800101d1980 m y0pora0103 ba
101 0# $apor
102 ## $aPT
200 1# $a<A >morgadinha dos canaviais$fJúlio Dinis
205 ## $a1ª ed
210 ## $aLisboa$cCírculo de Leitores$d[D. L. 1980]
215 ## $a478 p.$d21 cm
675 ## $a869.0-3$vmed$zpor$3787335
700 #1 $aDinis$bJúlio$cpseud.$320255
801 #0 $aPT$bBN$gRPC
966 ## $lBN$mMG$sL. 27496 V.
966 ## $lBPMP$mBPMP$sB6-1-106[3] $x1
966 ## $lBPRMAD$mBPRMAD$s02/3729
966 ## $lCMOPA$mCMOPA$s869-A 4005
998 ## $aFSE03 - 00482
Dublin Core (XML)
<dc>
<dc:title><A >morgadinha dos canaviais</dc:title>
<dc:creator>Dinis, Júlio</dc:creator>
<dc:subject>869.0-3, por</dc:subject>
<dc:description>Monografia</dc:description>
<dc:description>1ª ed</dc:description>
<dc:publisher>Círculo de Leitores</dc:publisher>
<dc:publisher>Lisboa</dc:publisher>
<dc:date>[D. L. 1980]</dc:date>
<dc:type>material textual, impresso</dc:type>
<dc:format>478 p., 21 cm</dc:format>
<dc:identifier>Id. do registo: 1535</dc:identifier>
<dc:identifier>Cota: BN-L. 27496 V.</dc:identifier>
<dc:identifier>Cota: BPMP-B6-1-106[3] </dc:identifier>
<dc:identifier>Cota: BPRMAD-02/3729</dc:identifier>
<dc:identifier>Cota: CMOPA-869-A 4005</dc:identifier>
<dc:language>por</dc:language>
</dc>
19
ONIX
http://www.editeur.org
•
Esquema utilizado pelos editores e livrarias on-line, define mais de 100 campos
como título, autor, assunto, identificadores, ...
•
Exemplo
<Product>
<RecordReference>1234567890</RecordReference>
<ISBN>9780307350176</ISBN>
<Contributor>
<PersonNameInverted>Neruda, Pablo</PersonNameInverted>
<BiographicalNote>Poeta chileno...</BiographicalNote>
</Contributor>
<Product>
20
UNIMARC Autoridade
Etiqueta de registo: 00595cx a2200193 45
001 20255
100 ## $a19980922apory0103 ba0
102 ## $aPT
152 ## $aRPC$bSIPOR
200 #1 $aDinis,$bJúlio,$cpseud.
400 #1 $aCoelho,$bJoaquim Guilherme Gomes,$f1839-1871$320256
400 #1 $aCoelho,$bJoaquim Guilherme Gomes$31254022
400 #1 $aAveleda,$bDiana de,$cpseud.$3925848
400 #0 $aCecília,$cpseud.$3925849
675 ## $a869.0 Dinis, Júlio .09$vBN$zpor
675 ## $a929 Dinis, Júlio$vBN$zpor
801 #0 $aPT$bBN$c19901218
810 ## $aAndrade, A. Guerra-Dic. de Pseud.
830 ## $aRomancista, novelista e autor teatral. Médico
21
MODS (http://www.loc.gov/standards/mods/)
<mods version="3.0" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-0.xsd">
<titleInfo><title>2001 bluegrass odyssey [sound recording].</title></titleInfo>
<name type="corporate">
<namePart>Roustabouts (Musical group)</namePart>
<role><roleTerm type="code">prf</roleTerm></role>
</name>
<typeOfResource>sound recording</typeOfResource>
<originInfo>
<place><placeTerm authority="marccountry" type="code">ncu</placeTerm></place>
<place><placeTerm type="text">Charlotte, NC</placeTerm></place>
<publisher>Lamon Records</publisher>
<dateIssued>p1980</dateIssued>
<dateIssued encoding="marc">1980</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<language><languageTerm authority="iso639-2b" type="code">eng</languageTerm></language>
<physicalDescription>
<extent>1 sound disc : analog, 33 1/3 rpm ; 12 in.</extent>
</physicalDescription>
<tableOfContents>Bluegrass odyssey -- Hills of Tennessee -- Sassafrass -- Muddy river -- Take your shoes off Moses -- Don't let
Smokey Mountain smoke get in your eyes -Farewell party -- Faded love -- Super sonic bluegrass -- Old love letters -- Will the
circle be unbroken.</tableOfContents>
<note>Brief record.</note>
<note type="performers">Performed by the Roustabouts.</note>
<subject authority="lcsh"><topic>Country music</topic><temporal>1971-1980.</temporal></subject>
<subject authority="lcsh"><topic>Bluegrass music</topic><temporal>1971-1980.</temporal></subject>
<classification authority="lcc">Lamon Records LR-4280</classification>
<recordInfo>
<recordContentSource>DLC</recordContentSource>
<recordCreationDate encoding="marc">940829</recordCreationDate>
<recordChangeDate encoding="iso8601">19940830080228.8</recordChangeDate>
<recordIdentifier>5718053</recordIdentifier>
22
</recordInfo>
</mods>
Dublin Core
Um “set” de elementos (atributos) e não formato!!!
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
title - O nome dado ao recurso.
creator - A entidade responsável em primeira instância pela existência do recurso.
subject - O tópico do conteúdo do recurso.
description – Uma descrição do conteúdo do recurso
publisher - Entidade responsável por tornar o recurso acessível.
contributor - Entidade responsável por qualquer contribuição para o conteúdo do recurso.
date - Uma data associada a um evento do ciclo de vida do recurso.
type - A natureza ou género do conteúdo do recurso.
format - A manifestação física ou digital do recurso.
identifier - Uma referência não ambígua ao recurso, definida num determinado contexto.
source - Uma referência a um recurso de onde o presente recurso possa ter derivado.
language - A língua do conteúdo intelectual do recurso.
relation - Uma referência a um recurso relacionado.
coverage - Cobertura geográfica ou temporal do recurso
rights - Informação de direitos sobre o recurso ou relativos ao mesmo.
23
Exemplo “Dublin Core em RDF”
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description>
<dc:creator>Karl Mustermann</dc:creator>
<dc:title>Algebra</dc:title>
<dc:subject>mathematics</dc:subject>
<dc:date>2000-01-23</dc:date>
<dc:language>EN</dc:language>
<dc:description>An introduction to algebra</dc:description>
</rdf:Description>
</rdf:RDF>
24
MPEG-7
• MPEG-7 Visual – the Description Tools dealing with
Visual descriptions.
• MPEG-7 Audio – the Description Tools dealing with
Audio descriptions
• MPEG-7 Multimedia Description Schemes - the
Description Tools dealing with generic features and
multimedia descriptions.
• MPEG-7 Description Definition Language - the
language defining the syntax of the MPEG-7 Description
Tools and for defining new Description Schemes.
25
MPEG-7 MDS
<Mpeg7>
<Description xsi:type="SemanticDescriptionType">
<Semantics>
<Label>
<Name> Carro </Name>
</Label>
<Definition>
<FreeTextAnnotation>
Carro com motor e quatro rodas
</FreeTextAnnotation>
</Definition>
<MediaOccurrence>
<MediaLocator>
<MediaUri> image.jpg </MediaUri>
</MediaLocator>
</MediaOccurrence>
</Semantics>
</Description>
</Mpeg7>
26
MPEG-7 Classification Schemes
STANDARD
MPEG-7 Schema
Examples:
• Creation DS
• Agent DS
• Semantic DS
MPEG-7 Standard
Schema (Syntax)
MPEG-7 Registration
Authority (Terms)
MPEG-7
Description
Schemes (DS) &
Descriptors (D)
MPEG-7
Classification
Schemes (CS) &
Controlled
Terms
MPEG-7 CS
Examples:
• Genre CS
• Role CS
• Format CS
3rd Party
Classification
Schemes (CS)
& Controlled
Terms
MPEG-7 CS
Registration
Examples:
• Sports CS
• News CS
• TGM-I CS
EXTENSION
MPEG-7
Extension
Examples:
• Broadcast
DS
• Rhythm DS
• Graphics DS
3rd
Party
MPEG-7
Extensions
(DS & D)
MPEG-7 Description
27
Sobre sistemas de classificação...
•
•
•
•
DDC – Dewey Decimal Classification
UDC – Universal Decimal Classification
LCSH – Library of Congress Subject Headings
CCS - ACM Computing Classification System
– http://www.acm.org/class/1998/
• ...
28
DDC e UDC
DDC
000 – Computer science,
information, and general works
100 – Philosophy and psychology
200 – Religion
300 – Social sciences
400 – Language
500 – Science
600 – Technology
700 – Arts and recreation
800 – Literature
900 – History and geography
UDC
0 - GENERALITIES
1 - PHILOSOPHY. PSYCHOLOGY
2 - RELIGION. THEOLOGY
3 - SOCIAL SCIENCES
4 - VACANT
5 - NATURAL SCIENCES
6 - TECHNOLOGY
7 - THE ARTS
8 - LANGUAGE. LINGUISTICS.
LITERATURE
9 - GEOGRAPHY. BIOGRAPHY.
HISTORY
29
Metadata Registries
30
ISO/IEC 11179
Information Technology - Metadata registries (MDR)
< http://metadata-stds.org/11179/
>
• 11179-1: Framework
– Introduces and discusses fundamental ideas of data elements, value domains, data element concepts,
conceptual domains, and classification schemes essential to the understanding of this set of standards and
provides the context for associating the individual parts of ISO/IEC 11179.
• 11179-2: Classification
– Provides a conceptual model for managing classification schemes. There are many structures used to
organize classification schemes and there are many subject matter areas that classification schemes
describe. So, this Part also provides a two-faceted classification for classification schemes themselves.
• 11179-3: Registry metamodel and basic attributes
– Specifies a conceptual model for a metadata registry, and a set of basic attributes for metadata for use
when a full registry solution is not needed.
• 11179-4: Formulation of data definition
– Provides guidance on how to develop unambiguous data definitions. A number of specific rules and
guidelines are presented in ISO/IEC 11179-4 that specify exactly how a data definition should be formed.
A precise, well-formed definition is one of the most critical requirements for shared understanding of an
administered item; well-formed definitions are imperative for the exchange of information. Only if every
user has a common and exact understanding of the data item can it be exchanged trouble-free.
• 11179-5: Naming and identification principles
– Provides guidance for the identification of administered items. Identification is a broad term for
designating, or identifying, a particular data item. Identification can be accomplished in various ways,
depending upon the use of the identifier. Identification includes the assignment of numerical identifiers
that have no inherent meanings to humans; icons (graphic symbols to which meaning has been assigned);
and names with embedded meaning, usually for human understanding, that are associated with the data
item's definition and value domain.
• 11179-6: Registration
– Provides instruction on how a registration applicant may register a data item with a central Registration
Authority and the allocation of unique identifiers for each data item. Maintenance of administered items
31
already registered is also specified in this document.
Perguntas?
32