Mudanças entre as edições de "Indexacao:adicionando facetas"
Diegomacedo (disc | contribs) |
Diegomacedo (disc | contribs) |
||
(2 edições intermediárias de um usuário não apresentadas) | |||
Linha 55: | Linha 55: | ||
Veja development:architecture:solr_index_schema#dynamic_field_suffixes|this page]] para todos os sufixos disponíveis. | Veja development:architecture:solr_index_schema#dynamic_field_suffixes|this page]] para todos os sufixos disponíveis. | ||
+ | |||
+ | ==== Índice não existe, tradução necessária ==== | ||
+ | |||
+ | //Exemplo: tipos de instrumentos para música // | ||
+ | |||
+ | Para dados codificados (como dados encontrados nos campos 007, 008 ou vários 04X), nós devemos primeiro mapear os dados para strings de textos. Felizmente, o formato MARC está bem documentado e as listas de que cada código significa estão facilmente disponíveis nos [[http://www.loc.gov/marc/marcdocz.html|MARC Code Lists]] e na OCLC's [[http://www.oclc.org/bibformats/en/|Formats and Standards page]]. | ||
+ | |||
+ | Crie um arquivo texto em import/solrmarc com o nome "algumacoisa.properties". Neste caso, criei o arquivo import/solrmarc/instrument_map.properties contendo os mapeamentos. O arquivo traduzirá as duas letras códigos usados no campo MARC 048 em texto legível. Cada linha do arquivo contém um código único possível e sua tradução. Exemplo: | ||
+ | |||
+ | ka = Piano | ||
+ | kb = Órgão | ||
+ | kc = Cravo | ||
+ | kd = Clavicórdio | ||
+ | |||
+ | Etc. | ||
+ | |||
+ | Em In import/marc.properties (ou do arquivo [[indexing:solrmarc:local_marc_mappings|local MARC mappings]], se você quiser separar suas alterações locais dois padrões fornecidos pelo VuFind), nós adicionamos a seguinte linha: | ||
+ | |||
+ | instrument_facet = 048a[0-1], instrument_map.properties | ||
+ | |||
+ | Nota: Os números entre parênteses indicam que o sistema deve olhar apenas os primeiros dois bytes 048 do subcampo de um campo (0-1 média de posição 0 para a posição 1). Uma vírgula separa as informações do campo do nome do arquivo usado para traduzir os dados, neste caso, instrument_map.properties. | ||
+ | |||
+ | A linha que define o novo índice deve ser adicionada ao arquivo schema.xml do Solr no arquivo (found in solr/biblio/conf na sua instalação do VuFind) e uma linha para a nova faceta será adicionado em [[configuration:files:facets.ini]] (veja acima para obter instruções). | ||
+ | |||
+ | ==== Solução de problemas ==== | ||
+ | |||
+ | ===== String vs. campos textos ===== | ||
+ | |||
+ | Se você configurar um campo faceta e ver as palavras individuais ao invés de valores faceta completos, isso provavelmente significa que você tem facetado um campo analisado (geralmente do tipo "text" em [[development:architecture:solr_index_schema|VuFind's Solr schema]]). Solr faceting exibe os termos armazenados no índice, não o texto bruto original fornecido no índice de tempo. Assim, se você faceta em um campo analisados, marcados e manipula strings, valores faceta estranhos podem aparecer para o usuário final. Na maioria das vezes, você só quer faceta em campos de cadeia simples para evitar este problema. É por isso que o esquema padrão inclui alguns valores aparentemente duplicados - é geralmente necessário usar campos diferentes para tarefas orientadas para a busca e orientada a faceta. |
Edição atual tal como às 16h00min de 12 de abril de 2016
Índice |
Adicionando facetas
//Estas indicações são baseadas no excelente documentação fornecida pelo projeto [[1]]. Abaixo está uma versão simplificada. Para obter informações mais detalhadas sobre a indexação personalizado e tradução, [| Veja a wiki Solrmarc].//
Adicionando uma faceta para a caixa de busca é um procedimento relativamente simples. Porque facetas dependem de um índice, estas instruções supõem que nós estamos começando com um dos três cenários possíveis:
1. O índice a ser utilizado já existe
2. Nenhum índice existe atualmente; os dados no registro MARC será indexado diretamente (ou seja, dados já são string de texto sem a necessidade ou desejo de normalização)
3. Nenhum índice existe atualmente; os dados são codificados e terão de ser primeiramente traduzidos em strings de texto.
Índice existente
// Exemplo usado: Adicionando a data de publicação como uma faceta //
Primeiro verifique a existência do índice e se certifique de que contém os dados que deseja. /import/marc.properties contém o mapeamento de base de campos MARC para o índice solr. Cada linha do arquivo é um único índice. O nome do índice Solr é antes do sinal de igual. Imediatamente após o sinal de igual é uma ou mais combinações do número tag MARC de três dígitos e quaisquer subcampos que são indexados juntos. Dois pontos separa diferentes áreas ou subáreas de ser indexados separadamente. Um número entre parênteses indica o byte de posição a ser indexado. "First", no final da linha significa que apenas o primeiro campo serão indexados.
No nosso exemplo, o índice publishDate é um índice personalizado não puxada diretamente de um tag MARC. A DateOfPublication rotina de indexação personalizada desde a data para o indexador, mas nós não precisamos saber como ele faz isso para continuar. Nós identificamos que o índice em questão é chamado publishDate, que é tudo o que precisamos agora.
O arquivo configuration:files:facets.ini contêm a listas de facetas a serem visualizadas. Cada linha é uma faceta, na forma:
SolrIndexName = Facet Display Name
(Em uma instalação limpa, o que inclui as duas primeiras facetas, Instituição e Biblioteca, que não podem ser necessários. Eles podem ser comentada por inserção de um ponto e vírgula no início da linha). Para adicionar a data de publicação como uma faceta, basta adicionar a seguinte linha para o arquivo:
publishDate = Publication Year
- Note-se que as facetas são exibidas em ordem; se publishDate é adicionado na parte inferior da lista, ele aparecerá na parte inferior da caixa de busca abaixo do resto.
As alterações são imediatamente refletidas na página de resultados de busca.
Se, devido a erros de digitação, etc, um índice inexistente é adicionado à lista, isso vai quebrar a caixa de busca completamente e as facetas não serão exibidas.
O índice não existe, nenhuma tradução necessários
// Exemplo: uma faceta gênero personalizado baseado nos campos gênero título e subcampos //
Se a faceta desejada já não é um índice existente, é preciso primeiro criar o índice. Isto vai exigir a re-indexação de toda a base de dados.
O arquivo /import/marc.properties mapeia campos e subcampos MARC a um índice. Para uma descrição mais detalhada do formato de arquivo do que o previsto anteriormente, veja [| a documentação SolrMarc]..
Neste exemplo, quereremos usar as strings encontradas no 655 subcampo a, e subcampo v e dados dos campos 650, 651 e 600. O índice será chamado de "allgenre". Para fazer isso, nós adicionamos a seguinte linha no arquivo marc.properties:
allgenre = 655ab:650v:600v:651v
Agora precisamos dizer ao Solr o que fazer com o novo índice. O arquivo /solr/biblio/conf/schema.xml define os campos no Solr. Na seção <fields>, adicionamos
<field name="allgenre" type="textFacet" indexed="true" stored="true" multiValued="true" termVectors="true"/>
Após o banco de dados ter sido reindexado, o índice allgenre existirá. A faceta pode ser adicionada no arquivo facets.ini como descrito acima.
Um atalho útil - Campos Dinâmicos (Dynamic Fields)
Se você está usando o VuFind 1.3 ou mais recente, você pode tirar vantagens dos campos dinâmicos do Solr para evitar de modificar seu esquema. VuFind é configurado para reconhecer certos sufixos de campos e tratá-los como novos campos sem a necessidade de definições explicitas. No exemplo acima, nós podemos de usar o nome do campo allgenre_txtF_mv em vez de allgenre no marc.properties e pular a etapa do schema.xml.
Veja development:architecture:solr_index_schema#dynamic_field_suffixes|this page]] para todos os sufixos disponíveis.
Índice não existe, tradução necessária
//Exemplo: tipos de instrumentos para música //
Para dados codificados (como dados encontrados nos campos 007, 008 ou vários 04X), nós devemos primeiro mapear os dados para strings de textos. Felizmente, o formato MARC está bem documentado e as listas de que cada código significa estão facilmente disponíveis nos [Code Lists] e na OCLC's [and Standards page].
Crie um arquivo texto em import/solrmarc com o nome "algumacoisa.properties". Neste caso, criei o arquivo import/solrmarc/instrument_map.properties contendo os mapeamentos. O arquivo traduzirá as duas letras códigos usados no campo MARC 048 em texto legível. Cada linha do arquivo contém um código único possível e sua tradução. Exemplo:
ka = Piano kb = Órgão kc = Cravo kd = Clavicórdio
Etc.
Em In import/marc.properties (ou do arquivo local MARC mappings, se você quiser separar suas alterações locais dois padrões fornecidos pelo VuFind), nós adicionamos a seguinte linha:
instrument_facet = 048a[0-1], instrument_map.properties
Nota: Os números entre parênteses indicam que o sistema deve olhar apenas os primeiros dois bytes 048 do subcampo de um campo (0-1 média de posição 0 para a posição 1). Uma vírgula separa as informações do campo do nome do arquivo usado para traduzir os dados, neste caso, instrument_map.properties.
A linha que define o novo índice deve ser adicionada ao arquivo schema.xml do Solr no arquivo (found in solr/biblio/conf na sua instalação do VuFind) e uma linha para a nova faceta será adicionado em configuration:files:facets.ini (veja acima para obter instruções).
Solução de problemas
String vs. campos textos
Se você configurar um campo faceta e ver as palavras individuais ao invés de valores faceta completos, isso provavelmente significa que você tem facetado um campo analisado (geralmente do tipo "text" em VuFind's Solr schema). Solr faceting exibe os termos armazenados no índice, não o texto bruto original fornecido no índice de tempo. Assim, se você faceta em um campo analisados, marcados e manipula strings, valores faceta estranhos podem aparecer para o usuário final. Na maioria das vezes, você só quer faceta em campos de cadeia simples para evitar este problema. É por isso que o esquema padrão inclui alguns valores aparentemente duplicados - é geralmente necessário usar campos diferentes para tarefas orientadas para a busca e orientada a faceta.