Uma pequena introdução ao Elasticsearch, para bibliotecários

Por que aprender Elasticsearch, se sou bibliotecário? Minha resposta simples para essa pergunta é que para se trabalhar em uma equipe multidisciplinar, é bastante importante entender ao menos os principais conceitos e melhores práticas de outras áreas. Além é claro de ser um diferencial competitivo na sua carreira.

Temos que começar rapidamente pela novidade essencial, que são os Banco de Dados não-relacionais (NoSQL) (Ops, não pode citar wikipédia, né?). Fiz uma pesquisa básica na BRAPCI e no RPPBCI e não encontrei nenhum resultado para os termos: elasticsearch, mongodb ou nosql, mas em compensação, uns 30 por XML. Então, cabe uma pequena explicação do que muda:

Primeiro, é necessário deixar claro que em tecnologia, não é porque você começa a adotar uma tecnologia que necessáriamente irá abandonar a anterior. Então, NoSQL não é necessariamente uma evolução do modelo SQL. Mas o que muda na prática?

Nos banco de dados relacionais, a informação é armazenada em tabelas, imagine a tabela LIVROS:

Titulo Autor Editora
Introdução à Biblioteconomia Edson Nery da Fonseca Briquet de Lemos Livros
Missão do bibliotecário José Ortega y Gasset Briquet de Lemos Livros

E as consultas, são por SQL:

SELECT * FROM LIVROS
Para retornar todos os títulos ou:
SELECT * FROM LIVROS
WHERE EDITORA = "Briquet de Lemos Livros"

Para recuperar todos os títulos de uma determinada editora.

Fiz um pequeno estudo de como os SIGBs livres armazenam os dados em banco de dados relacionais, para quem tiver interesse.

No modelo NoSQL, é um banco de dados que armazena o documento, mas um documento JSON. O JSON é um formato que tem algumas vantagens em relação ao XML. Vamos ver um exemplo dos dois:

< ?xml version="1.0" encoding="UTF-8"? >
< titulo >Introdução à Biblioteconomia< /titulo >
< autor >Edson Nery da Fonseca< /autor >
< editora >Briquet de Lemos Livros< /editora >
< /xml >

O XML, assim como o MARC, é um bom formato de intercâmbio de dados. Já o JSON ficaria assim:

{
"Titulo":"Introdução à Biblioteconomia",
"Autor": "Edson Nery da Fonseca"
"Editora": "Briquet de Lemos Livros"
}

A vantagem, neste caso, além de ser um formato mais enxuto, usar arrays, e pode ser usado diretamente nos bancos NoSQL, além é claro de ser o formato padrão do Javascript e por isso é usado amplamente na Internet por todas as APIs. Já é possível descrever documentos inteiros em JSON ou XML. Só como curiosidade, em 2007, eu juntei o que eu li sobre gerenciar documentos integrais em um pequeno slide, e vejo que hoje o modelo, precisa de adaptação, mas não perdeu totalmente o sentido:

Mas voltando ao Elasticsearch (dá para usar também o MongoBD, tendo cada um uma vantagem diferente sobre o outro). É um software livre, que faz parte de um conjunto chamado Elastic Stack.

A diferença que irei destacar em relação ao modelo relacional lá de cima é que a informação é armazenada no próprio documento e não tem mais uma estrutura fixa de dados. No modelo lá de cima, se quiser colocar a informação sobre a função do autor, tem que criar uma nova coluna na tabela. Para dois autores com duas funções diferentes, a coisa começa a complicar. Ou se criam 4 colunas, duas para o nome, duas para a função, ou se cria uma nova tabela, e faz o relacionamento entre elas. Mas é preciso uma modelagem prévia do modelo antes de entrar qualquer dado. No NoSQL, é bem mais simples, é só alterar o JSON. Como por exemplo no modelo abaixo:

{
"Titulo":"Introdução à Biblioteconomia",
"Autoria": {"nome":"Edson Nery da Fonseca",
"função":"Autor"
},
"Editora": "Briquet de Lemos Livros"
}

A desvantagem é que isso possibilita ter mais erros em relação a consistência dos dados.
Outro grande problema, é a esquematização da descrição. Há estudos em usar os nomes MARC e sua lógica de estrutura para os nomes dos campos. Eu particularmente não gosto desta abordagem. Eu optei por usar o formato schema.org. É um esquema bem completo para a descrição de qualquer tipo de objeto. Mas podemos utilizar qualquer esquema.

O Elasticsearch tem duas principais funcionalidades, pensando em recuperação da informação: A recuperação e a criação de facetas (ou agregações).

Ele não aceita consultas em SQL e tem um vocabulário próprio para consultas: Query DSL. E também um para construção de facetas: Aggregations.

Em relação a consulta, se destacam com alguns conceitos diferente em relação aos bancos de dados relacionais: atribuição de notas e criação de indices de palavras. Um campo título, por exemplo, ao ser indexado, é indexado por suas palavras separadas. Ele também cria um campo para o valor como um todo. Mas tem que buscar em um campo diferenciado com a palavra .keyword no final. Por exemplo, para uma busca no titulo acima, ele busca no índice de palavras “introdução” e “Biblioteconomia” e dá uma nota por maior proximidade de correspondência. Um chute: a busca acima daria uma nota de 80.333. Mas algum titulo como “Estudando a Biblioteconomia no Brasil”, daria uma nota de 30.455 para a mesma busca. Com isso, é possível definir a relevância, e inclusive, não exibir resultados com notas muito baixas.

Para as facetas, é necessário usar o valor completo do campo, e não ele quebrado em palavras. Por isso é preciso usar o campo .keyword. Por exemplo, o campo editora.keyword permite saber quantas vezes cada ocorrência aparece no campo editora. É possível em bancos relacionais usar o “GROUP BY”, mas ele tem menos funcionalidades.

Teria muitos mais detalhes, mas como a idéia era escrever apenas uma pequena introdução, vou só mostrar como seria um exemplo de inclusão de documento, consulta e agregação (O Banco só aceita comandos REST):

INCLUSÃO:

PUT catalogo/livros/1
{
"Titulo":"Introdução à Biblioteconomia",
"Autoria": {"nome":"Edson Nery da Fonseca",
"função":"Autor"
},
"Editora": "Briquet de Lemos Livros"
}

CONSULTA SIMPLES (Retorna os registros com autor “Edson Nery da Fonseca” ):

GET catalogo/livros/_search
{
"query" : {
"term" : { "Autoria.nome" : "Edson Nery da Fonseca" }
}
}

FACETA SIMPLES (Retorna todos os valores de editoras e suas quantidades):

GET catalogo/livros/_search
{
"size": 0,
"aggregations": {
"my_agg": {
"terms": {
"field": "Editora"
}
}
}
}

Só para finalizar, o Elasticsearch aguenta milhões de registros e tem uma ferramenta poderosa de Business Inteligence que é o Kibana. Posso escrever um post depois só sobre ele.

Querem testar os resultados? O Repertório da Produção Periódica Brasileira de Ciência da Informação – RPPBCI é um exemplo de busca usando o Elasticsearch. Ah, a resposta no RPPBCI é um pouco mais lenta, por que na hora de gerar o resultado, nós consultamos o facebook e armazenamos a resposta no banco de dados. Mas vale para testar as funcionalidades.

Indexação do catálogo no Google

Lá em 2014, eu e o Giuliano Ferreira conversamos sobre como poderíamos indexar nossos catálogos no Google. Depois ele apresentou um trabalho bacana no SNBU: “AUMENTANDO O ALCANCE E A VISIBILIDADE DE CATÁLOGOS ONLINE E REPOSITÓRIOS INSTITUCIONAIS COM A AJUDA DO GOOGLE.”. Então essa é uma idéia que estava martelando na minha cabeça desde aquela época.

Neste post vou mostrar o caminho que fizemos para tornar essa idéia algo real.

Atualmente temos um catálogo que pode ser indexado pelo google, mas não está sendo por uma questão importante, que é a limitação dele para receber muitos usuários. Começamos então a estudar uma maneira de contornar isso. E uma das soluções encontradas foi criar um OPAC independente, mas sincronizado, que possa receber toda a carga de uso sem sobrecarregar o sistema principal.

Desenvolvemos um software livre utilizando o ElasticSearch e PHP, muito inspirado no Vufind. O ElasticSearch, na minha opinião, é a melhor ferramenta de criação de índices e recuperação da informação no momento e PHP foi escolhida por ser uma linguagem simples, mas que é poderosa o suficiente.

A idéia principal por tras é pegar os registros MARC e transformá-los em JSON (formato padrão utilizado no Elasticsearch). Para os nomes dos campos, utilizamos o padrão schema.org. A vantagem em utilizar o Schema.org é que é um formato de metadados estruturados que o google utiliza, melhorando a indexação. O sistema tem em seu cabeçalho, os metadados estruturados no padrão JSON-LD utilizando o Schema.org.

É possível adaptar a aplicação para qualquer formato de entrada de metadados e sistema fonte de informação. E adaptar a interface para essa situação.

Atualmente temos 2 sistemas em produção utilizando esta lógica, ambos com os metadados catalogados em MARC, mas sendo sincronizados e oferendo uma forma alternativa de consulta:

Partituras da Universidade de São Paulo
Biblioteca Digital de Produção Intelectual da Universidade de São Paulo

Ainda não fizemos com o nosso catálogo principal.

Mas posso falar que são muitas as vantagens em indexar o catálogo no Google, mas a principal é ampliar a visibilidade de um acervo que até então o usuário teria que fazer uma busca individual em cada catálogo para saber que alguma instituição tem a obra que ele precisa. Essa lógica altera um pouco o fluxo de sistemas de busca federada.

Uma limitação ainda é que não controlamos totalmente o que é indexado, então não é possível garantir que o google irá indexar todos os seus conteúdos. Há estudos que mostram que o google tende a indexar somente uma porcentagem do conteúdo dos sites e nunca tudo. Então esta pode ser uma limitação importante a ser considerada.

Guia do usuário do Koha

O Koha é o primeiro software livre de Gestão de Bibliotecas e para mim o mais completo da atualidade. Ele tem todas as principais funcionalidades de um grande software. O IBICT está auxiliando Bibliotecas no país que queiram utilizar o software e um dos principais caminhos foi a criação de um Guia do Usuário. É parte do projeto do IBICT com a Secretaria Nacional da Juventude, mais especificamente da Coordenação de Articulação, Geração e Aplicação de Tecnologia (COAT), que o grande Milton Shintaku coordena. Foi concebido pela fantática equipe: Ingrid Schiessl, Jaqueline Rodrigues, Diego Macêdo, Priscila Rodrigues. Eu só dei uma pequena contribuição, mas agradeço a parceria.

Aproveitem, e fiquem a vontade para conversar comigo ou com a equipe do IBICT sobre o Koha. Um software livre que possibilita uma melhora nos serviços prestados pelas bibliotecas. Eu pude participar da implementação dele na Prefeitura de São Bernardo do Campo e os resultados foram bastante positivos. Espero que outras instituições, que estejam pensando em mudar de sistema, ou adotar um, possam considerar esta ferramenta.

O Guia do usuário do Koha pode ser baixado em:

http://bibjuventude.ibict.br/jspui/handle/192/170

Ou caso queiram a versão impressa, podem retirar no IBICT, em Brasília.

Armazenamento do Formato MARC em Sistemas de Gerenciamento de Bibliotecas

Armazenamento do Formato MARC em Sistemas de Gerenciamento de Bibliotecas

Introdução

O Formato MARC (Machine-Readable Cataloging) é um formato controverso. Muitos autores o defendem, mas já existem diversos autores que questionam a sua adoção. O presente estudo irá se aprofundar nessa discussão, ao estudar como o MARC está sendo adotado pelos Sistemas de Gerenciamento de Bibliotecas (SGBs) para compreender as implicações da sua adoção.

Formato MARC

Segundo  AVRAM (1975), as pesquisas sobre as possibilidades de uso de técnicas automatizadas para as operações internas da Library of Congress (LC) se iniciaram no final da década de 1950. Devido ao interesse generalizado por essas pesquisas, o Bibliotecário do Congresso solicitou um financiamento para o Council on Library Resources (CLR) e como resultado foi publicado o estudo: “Automation and the Library of Congress: a Survey Sponsored by the Council on Library Resources, Inc.” em 1963. Neste período, a CLR firmou um contrato com a LC para estudar possíveis métodos de conversão de dados das fichas catalográficas da LC em um formato legível por máquina com a finalidade de imprimir produtos bibliográficos por computador. Em 1965, foi publicado o relatório preliminar: “A Proposed Format for a Standardized Machine-Readable Catalog Record: A Preliminary Draft”. Que resultou em um financiamento em dezembro de 1965 para testar a viabilidade e utilidade da distribuição de dados catalográficos em formato legível por máquina da LC para outras bibliotecas, este projeto foi chamado de MARC (Machine-Readable Cataloging). O projeto piloto foi concluído em junho de 1968 e neste mesmo ano, a LC iniciou seu serviço de distribuição MARC (MARC Distribution Service).

O Formato MARC tem sua essência descrita de seguinte maneira por AVRAM (1975):

“The philosophy behind MARC II was the design of one format structure (the physical representation on a machine-readable medium) capable of containing bibliographic information for all forms of material (books, serials, maps, music, journal, articles, etc). The structure, or “empty container”, the content designators (tags, indicators, and subfield codes) used to explicitly identify or to additionally characterize the data elements, and the content, the data itself (author's name, titles, etc), are the three components of the format.” (AVRAM, 1975)

Problema de pesquisa

THOMALE (2010) fez uma comparação entre o desenvolvimento do formato MARC ao longo do tempo e o desenvolvimento de tecnologias de representação de dados de computador:

“O formato MARC foi pensado no início dos anos 1960 e teve seu primeiro piloto em 1966. Agora tem mais de 40 anos de idade. Considerando somente os avanços na representação de dados de computador que ocorreram desde então, o mundo é diferente deste MARC como foi concebido. 1966 foi três anos antes em que o Dr. Edgar F. Codd publicou seu primeiro artigo descrevendo um modelo relacional de dados como um IBM Research Report, e quatro anos antes dele rever o documento e publicá-lo mais amplamente em Communications for the ACM. Oito anos antes de Donald Chamberlin e Raymond Boyce publicarem seu primeiro trabalho em SEQUEL (SQL) e dez anos antes de Peter Chen propor seu primeiro modelo de Entidade-Relacionamento. Nós que trabalhamos com tecnologia e sistemas de biblioteca não podemos ver o MARC somente através de uma lente colorida por 44 anos de rápida mudança tecnológica (Figura 1)" (THOMALE, 2010)

fig1.png

Figura 1. Linha do tempo comparando a criação do MARC aos principais desenvolvimentos em software, redes e representação de dados entre 1960 e 1980 (THOMALE, 2010)

E THOMALE (2010) nos demonstra o problema, ao afirmar que o MARC não foi inventado para modelar sistemas de recuperação da informação computadorizados. Sua proposta original era automatizar os processos e tarefas do departamento de serviços técnicos da LC. As mesmas regras que determinaram como os dados bibliográficos eram armazenados e exibidos nas fichas bibliográficas são as regras que determinaram como os dados são formatados e armazenados nos registros MARC. De fato, apesar de ter mudado ao longo do tempo, as regras de catalogação foram criadas antes do advento da tecnologia dos computadores modernos.

KOSTER (2009) também questiona: “A questão está posta: o que na terra pode ter sido a razão para armazenar metadados bibliográficos em formatos de intercâmbio como o MARC?”

O armazenamento de registros uma questão negligênciada na gestão dos SGBs. Se leva em conta a compatibilidade com o formato MARC, mas em nenhum momento se questiona como o SGB armazena e gerencia os registros.

Levantamento Bibliográfico

Foram pesquisadas as Bases BRAPCI, utilizando o termo mais abrangente (MARC) e não foram encontrados nenhum resultado sobre a temática deste artigo na literatura nacional.

Objetivos

Realizar um mapeamento de como os Sistemas de Gerenciamento de Bibliotecas atuais armazenam os registros em sua Base de Dados  para  compreender as implicações da escolha do formato nestes sistemas.

Metodologia

A presente metodologia terá os seguintes passos:

  • Identificar SGBs compatíveis com o formato MARC;
  • Analisar a estrutura dos bancos de dados destes sistemas no que se refere ao armazenamento de registros bibliográficos;
  • Consolidar os modelos;
  • Identificar as implicações resultantes das escolhas destes modelos.

Como amostra, foram selecionados somente softwares livres, uma vez que é necessário ter amplo acesso ao software, código, banco de dados e documentação do sistema. Foram escolhidos os seguintes softwares: Koha e OpenBiblio, em que criamos 1 registro em cada um deles para estudarmos como as informações bibliográficas são armazenadas. Os banco de dados foram diagramados utilizando o software: SchemaSpy[1]

Catalogado o Livro: Introdução à Biblioteconomia, do Edson Nery da Fonseca

Registro original:

=LDR  00919nam a2200289 a 4500

=005  20150222225003.0

=008  120209r20102007bl\\\\\\\\\\\\000\0\por\d

=020  \\$a8585637323

=020  \\$a9788585637323

=040  \\$aUSP/SIBI

=041  0\$apor

=044  \\$abl

=092  0\$a020

=098  01$a02

=100  \\$aFonseca, Edson Nery da

=245  10$aIntrodução à biblioteconomia$cEdson Nery da Fonseca ; prefácio de Antônio Houaiss

=250  \\$a2. ed

=260  \\$aBrasília$bBriquet de Lemos$c2010, c2007

=300  \\$a152 p

=500  \\$a1.ª reimpressão da 2.ed. de 2007

=650  \0$aLibrary science

=650  \0$aLibrary science$vLiterary collections

=650  \7$aBIBLIOTECONOMIA$2larpcal

=700  \\$aHouaiss, Antônio$4pref

Resultados

Koha

O Koha[2] é o primeiro Software de Gerenciamento de Bibliotecas Livre. Foi desenvolvido inicialmente na Nova Zelândia pela Katipo Communications Ltd em 2000 para a Horowhenua Library Trust. Atualmente é mantido por uma comunidade distribuida globalmente de desenvolvedores e empresas de softwares.  

O Koha armazena os registros bibliográficos nas seguintes tabelas:

biblio

Column

Type

Size

Nulls

Auto

Default

Children

Parents

Comments

biblionumber

int

10

 √

aqorders

biblioimages

biblioitems

hold_fill_targets

oai_sets_biblios

old_reserves

ratings

reserves

reviews

tags_all

tags_index

virtualshelfcontents

unique identifier assigned to each bibliographic record

frameworkcode

varchar

4

foriegn key from the biblio_framework table to identify which framework was used in cataloging this record

author

mediumtext

16777215

 √

null

statement of responsibility from MARC record (100$a in MARC21)

title

mediumtext

16777215

 √

null

title (without the subtitle) from the MARC record (245$a in MARC21)

unititle

mediumtext

16777215

 √

null

uniform title (without the subtitle) from the MARC record (240$a in MARC21)

notes

mediumtext

16777215

 √

null

values from the general notes field in the MARC record (500$a in MARC21) split by bar (|)

serial

bit

0

 √

null

Boolean indicating whether biblio is for a serial

seriestitle

mediumtext

16777215

 √

null

copyrightdate

smallint

5

 √

null

publication or copyright date from the MARC record

timestamp

timestamp

19

CURRENT_TIMESTAMP

date and time this record was last touched

datecreated

date

10

the date this record was added to Koha

abstract

mediumtext

16777215

 √

null

summary from the MARC record (520$a in MARC21)

biblioitens

Column

Type

Size

Nulls

Auto

Default

Children

Parents

Comments

biblioitemnumber

int

10

 √

items

primary key, unique identifier assigned by Koha

biblionumber

int

10

0

biblio

foreign key linking this table to the biblio table

volume

mediumtext

16777215

 √

null

number

mediumtext

16777215

 √

null

itemtype

varchar

10

 √

null

biblio level item type (MARC21 942$c)

isbn

varchar

30

 √

null

ISBN (MARC21 020$a)

issn

varchar

9

 √

null

ISSN (MARC21 022$a)

ean

varchar

13

 √

null

publicationyear

text

65535

 √

null

publishercode

varchar

255

 √

null

publisher (MARC21 260$b)

volumedate

date

10

 √

null

volumedesc

text

65535

 √

null

volume information (MARC21 362$a)

collectiontitle

mediumtext

16777215

 √

null

collectionissn

text

65535

 √

null

collectionvolume

mediumtext

16777215

 √

null

editionstatement

text

65535

 √

null

editionresponsibility

text

65535

 √

null

timestamp

timestamp

19

CURRENT_TIMESTAMP

illus

varchar

255

 √

null

illustrations (MARC21 300$b)

pages

varchar

255

 √

null

number of pages (MARC21 300$c)

notes

mediumtext

16777215

 √

null

size

varchar

255

 √

null

material size (MARC21 300$c)

place

varchar

255

 √

null

publication place (MARC21 260$a)

lccn

varchar

25

 √

null

library of congress control number (MARC21 010$a)

marc

longblob

2147483647

 √

null

full bibliographic MARC record

url

text

65535

 √

null

url (MARC21 856$u)

cn_source

varchar

10

 √

null

classification source (MARC21 942$2)

cn_class

varchar

30

 √

null

cn_item

varchar

10

 √

null

cn_suffix

varchar

10

 √

null

cn_sort

varchar

30

 √

null

normalized version of the call number used for sorting

agerestriction

varchar

255

 √

null

target audience/age restriction from the bib record (MARC21 521$a)

totalissues

int

10

 √

null

marcxml

longtext

2147483647

full bibliographic MARC record in MARCXML

Resultado

Tabela biblio

biblionumber

1689978

frameworkcode

BKS

author

Fonseca, Edson Nery da

title

Introdução à biblioteconomia

unititle

NULL

notes

1.ª reimpressão da 2.ed. de 2007

serial

0

seriestitle

NULL

copyrightdate

2007

timestamp

2015-02-23 01:50:03

datecreated

2015-02-22

abstract

NULL

Tabela biblioitems

biblioitemnumber

1689978

biblionumber

1689978

volume

NULL

number

NULL

itemtype

BK

isbn

8585637323 | 9788585637323

issn

NULL

ean

NULL

publicationyear

NULL

publishercode

Briquet de Lemos

volumedate

NULL

volumedesc

NULL

collectiontitle

NULL

collectionissn

NULL

collectionvolume

NULL

editionstatement

2. ed

editionresponsibility

NULL

timestamp

2015-02-23 01:50:03

illus

NULL

pages

152 p

notes

NULL

size

NULL

place

Brasília

lccn

NULL

marc

0x30303739326e616d206132323030323737206120343530303030353030313730303030303030383030343130303031373032303030313530303035383032303030313830303037333034303030313330303039313034313030303830303130343034343030303730303131323039323030303830303131393039383030303730303132373130303030333030303133343234353030393130303136343235303030313030303235353236303030343530303236353330303030313030303331303530303030333930303332303635303030323030303335393635303030343230303337393635303030323930303432313730303030333130303435303934323030313230303438313939393030323130303439331e32303135303232323232353030332e301e313230323039723230313032303037626c202020202020202020202020303030203020706f7220641e20201f61383538353633373332331e20201f61393738383538353633373332331e20201f615553502f534942491e30201f61706f721e20201f61626c1e30201f613032301e30311f6130321e20201f61466f6e736563612c204564736f6e204e6572792064611f39311e31301f61496e74726f6475c3a7c3a36f20c3a0206269626c696f7465636f6e6f6d69611f634564736f6e204e65727920646120466f6e73656361203b2070726566c3a163696f20646520416e74c3b46e696f20486f75616973731e20201f61322e2065641e20201f6142726173c3ad6c69611f6242726971756574206465204c656d6f731f63323031302c2063323030371e20201f6131353220701e20201f61312ec2aa207265696d7072657373c3a36f20646120322e65642e20646520323030371e20301f614c69627261727920736369656e63651e20301f614c69627261727920736369656e63651f764c6974657261727920636f6c6c656374696f6e731e20371f614249424c494f5445434f4e4f4d49411f326c61727063616c1e20201f61486f75616973732c20416e74c3b46e696f1f34707265661f39321e20201f326464631f63424b1e20201f63313638393937381f64313638393937381e1d

url

NULL

cn_source

ddc

cn_class

NULL

cn_item

NULL

cn_suffix

NULL

cn_sort

NULL

agerestriction

NULL

totalissues

NULL

marcxml

<?xml version="1.0" encoding="UTF-8"?>\n<record\n    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\n    xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"\n    xmlns="http://www.loc.gov/MARC21/slim">\n\n  <leader>00792nam a2200277 a 4500</leader>\n  <controlfield tag="005">20150222225003.0</controlfield>\n  <controlfield tag="008">120209r20102007bl            000 0 por d</controlfield>\n  <datafield tag="020" ind1=" " ind2=" ">\n    <subfield code="a">8585637323</subfield>\n  </datafield>\n  <datafield tag="020" ind1=" " ind2=" ">\n    <subfield code="a">9788585637323</subfield>\n  </datafield>\n  <datafield tag="040" ind1=" " ind2=" ">\n    <subfield code="a">USP/SIBI</subfield>\n  </datafield>\n  <datafield tag="041" ind1="0" ind2=" ">\n    <subfield code="a">por</subfield>\n  </datafield>\n  <datafield tag="044" ind1=" " ind2=" ">\n    <subfield code="a">bl</subfield>\n  </datafield>\n  <datafield tag="092" ind1="0" ind2=" ">\n    <subfield code="a">020</subfield>\n  </datafield>\n  <datafield tag="098" ind1="0" ind2="1">\n    <subfield code="a">02</subfield>\n  </datafield>\n  <datafield tag="100" ind1=" " ind2=" ">\n    <subfield code="a">Fonseca, Edson Nery da</subfield>\n    <subfield code="9">1</subfield>\n  </datafield>\n  <datafield tag="245" ind1="1" ind2="0">\n    <subfield code="a">Introdução à biblioteconomia</subfield>\n    <subfield code="c">Edson Nery da Fonseca ; prefácio de Antônio Houaiss</subfield>\n  </datafield>\n  <datafield tag="250" ind1=" " ind2=" ">\n    <subfield code="a">2. ed</subfield>\n  </datafield>\n  <datafield tag="260" ind1=" " ind2=" ">\n    <subfield code="a">Brasília</subfield>\n    <subfield code="b">Briquet de Lemos</subfield>\n    <subfield code="c">2010, c2007</subfield>\n  </datafield>\n  <datafield tag="300" ind1=" " ind2=" ">\n    <subfield code="a">152 p</subfield>\n  </datafield>\n  <datafield tag="500" ind1=" " ind2=" ">\n    <subfield code="a">1.ª reimpressão da 2.ed. de 2007</subfield>\n  </datafield>\n  <datafield tag="650" ind1=" " ind2="0">\n    <subfield code="a">Library science</subfield>\n  </datafield>\n  <datafield tag="650" ind1=" " ind2="0">\n    <subfield code="a">Library science</subfield>\n    <subfield code="v">Literary collections</subfield>\n  </datafield>\n  <datafield tag="650" ind1=" " ind2="7">\n    <subfield code="a">BIBLIOTECONOMIA</subfield>\n    <subfield code="2">larpcal</subfield>\n  </datafield>\n  <datafield tag="700" ind1=" " ind2=" ">\n    <subfield code="a">Houaiss, Antônio</subfield>\n    <subfield code="4">pref</subfield>\n    <subfield code="9">2</subfield>\n  </datafield>\n  <datafield tag="942" ind1=" " ind2=" ">\n    <subfield code="2">ddc</subfield>\n    <subfield code="c">BK</subfield>\n  </datafield>\n  <datafield tag="999" ind1=" " ind2=" ">\n    <subfield code="c">1689978</subfield>\n    <subfield code="d">1689978</subfield>\n  </datafield>\n</record>\n

Podemos observar que o Koha armazena os dados em linhas para a criação da página de detalhes e o MARC completo em um Blob, conforme Nelson (2013): “Currently MARC stored in MARCxml and Zebra reads the MARCxml blob”. Esse blob será posteriormente será usado para a indexação no banco de dados textual Zebra.

OpenBiblio

openbiblio.biblio

Column

Type

Size

Nulls

Auto

Default

Children

Parents

bibid

int

10

 √

biblio_copy

biblio_copy_fields

biblio_field

biblio_hold

biblio_status_hist

create_dt

datetime

19

last_change_dt

datetime

19

last_change_userid

int

10

material_cd

smallint

5

collection_cd

smallint

5

call_nmbr1

varchar

20

 √

null

call_nmbr2

varchar

20

 √

null

call_nmbr3

varchar

20

 √

null

title

text

65535

 √

null

title_remainder

text

65535

 √

null

responsibility_stmt

text

65535

 √

null

author

text

65535

 √

null

topic1

text

65535

 √

null

topic2

text

65535

 √

null

topic3

text

65535

 √

null

topic4

text

65535

 √

null

topic5

text

65535

 √

null

opac_flg

char

1

openbiblio.biblio_field

Column

Type

Size

Nulls

Auto

Default

Children

Parents

bibid

int

10

biblio

fieldid

int

10

 √

tag

smallint

5

ind1_cd

char

1

 √

null

ind2_cd

char

1

 √

null

subfield_cd

char

1

field_data

text

65535

 √

null

Resultado

Tabela biblio

bibid

3

create_dt`

2015-02-22 23:25:16

last_change_dt

2015-02-22 23:27:18

last_change_userid

1

material_cd

2

collection_cd

2

call_nmbr1

020

call_nmbr2

call_nmbr3

title

Introdução à biblioteconomia

title_remainder

responsibility_stmt

Edson Nery da Fonseca ; prefácio de Antônio Houaiss

author

Fonseca, Edson Nery da

topic1

Library science

topic2

Library science

topic3

BIBLIOTECONOMIA

topic4

topic5

opac_flg

Y

Tabela biblio_field

bibid

fieldid

tag

ind1_cd

ind2_cd

subfield_cd

field_data

3

1

82

N

N

a

020

3

2

20

N

N

a

8585637323

3

3

20

N

N

a

9788585637323

3

4

41

N

N

a

por

3

5

44

N

N

a

bl

3

6

250

N

N

a

2. ed

3

7

260

N

N

a

Brasília

3

8

260

N

N

b

Briquet de Lemos

3

9

260

N

N

c

2010, c2007

3

10

300

N

N

a

152 p

3

11

500

N

N

a

1.ª reimpressão da 2.ed. de 2007

3

12

700

N

N

a

Houaiss, Antônio

3

13

700

N

N

4

pref

O OpenBiblio utiliza a tabela biblio para armazenar as informações que serão disponibilizadas para a busca ou para a geração das páginas de detalhes do registro, e a tabela biblio_field para as demais informações.

Discussão

Apesar de o MARC ser um bom formato para intercâmbio, utilizá-lo dentro dos sistemas de informação impedem de se utilizar todo o potencial informativo do registro. Além de dificultar o gerenciamento desta informação pelos bibliotecários. É importante re-pensar os sistemas de armazenamento das informações bibliográficas nos sistemas de informações.

Referências

AVRAM, H. D. (1975). MARC; its history and implications. Washington, DC: Library of Congress. Disponível em: http://catalog.hathitrust.org/Record/002993527 . Acesso em: 30 dez 2014.

CHARLTON, Galen. Extending Koha using Linked Data. KohaCon 2014. Disponível em: http://zadi.librarypolice.com/~gmc/koha-linked-data/ . Acesso em: 01 jan 2015.

KOSTER, Lukas. Who needs MARC?. COMMONPLACE.NET, 2009. Disponível em: http://commonplace.net/2009/05/who-needs-marc/ . Acesso em: 30 dez 2014

NELSON, Joy. KohaCon13: What is after MARC???. ByWater Solutions, 2013. Disponível em: http://bywatersolutions.com/2013/10/16/kohacon13-marc/ . Acesso em: 30 dez 2014

OVERMYER, LaVahn Marie. Libraries, Technology, and the Need to Know. Ci. Inf, Rio de Janeiro, 1(2):67-71,1972. Disponível em: http://revista.ibict.br/ciinf/index.php/ciinf/article/view/1663 . Acesso em: 01 jan 2015.

TENNANT, Roy. MARC must die. Library Journal, 2002. Disponível em: http://lj.libraryjournal.com/2002/10/ljarchives/marc-must-die/ . Acesso em: 30 dez 2014

THOMALE, Jason. Interpreting MARC: Where’s the Bibliographic Data?. Code {4} Lib Journal. Issue 11, 2010-09-21. Disponível em: http://journal.code4lib.org/articles/3832 . Acesso em: 30 dez 2014

THE EUROPEAN LIBRARY. The European Library Open Dataset. Disponível em: http://www.theeuropeanlibrary.org/tel4/access/data/opendata . Acesso em: 01 jan 2015.

THE LIBRARY OF CONGRESS. MARC Standards (Network Development and MARC Standards Office, Library of Congress). Disponível em: http://www.loc.gov/marc/ . Acesso em: 30 dez 2014


[1] http://schemaspy.sourceforge.net/

[2] http://koha-community.org/

Todos os assuntos descritos nos Artigos de Revistas da área de CI e disponíveis em OAI-PMH

Assuntos

A computação permite que a gente consiga fazer coisas que antes demorariam muito tempo, em alguns minutos. Com isso, consegui levantar todos os assuntos das revistas de CI que tem OAI, em 2015-06-10, seguindo os seguintes passos:

– Harvesting do OAI utilizando o CATMANDU com output em JSON (Utilizei como base a lista “Revistas Brasileiras em Ciência da Informação” do Laboratório de Tecnológias Intelectuais – LTi” por dica do Prof. Ronaldo Araújo da UFAL.

– Inclusão dos registros (em um total de 15354) na base MONGODB.

– Extração das colunas URL e Assuntos em JSON.

– Tratamento desses dados no OpenRefine.

– Criação de visualização teste usando o Tableau Public.

Vocês podem acessar as visualizações aqui (Está dando problema no Chrome, só estou conseguindo acessar pelo Firefox)

Assuntos – 2015-06-10

Utilizem a vontade, mas será bacana se citarem a fonte.