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