Discussão:Metadados mínimos para Artigos de Periódicos (S as)

De Wiki.bireme.org/pt
Ir para: navegação, pesquisa

Dúvida 1: TYPE: vários campos são destinados a esse elemento. [5, 6, 9, 110 e 113]

Dúvida 2: CREATOR ou CONTRIBUTOR: [10 e 11]

Sobre essa dúvida encontrei essa documentação: http://mailman.mit.edu/pipermail/dspace-general/2006-January/000831.html

Dúvida 3: Campos [14 e 20]

podem ser eliminadas, pois são essenciais e quando o registro possui URL não é necessário seu preenchimento, porém, usado como base referencial, é ncessário manter os campos para Dublin Core

Definição: referência bibliográfica irá para IDENTIFIER.citation.

Dúvida 4: No OAI de SEARO

os dados carregados vem até o nível de elemento. Assim sendo, todos os qualifiers são ignorados e depende de análise humana a Definição de quais campos receberão os dados. [30,31 e 32]

Dúvida 5: Campos de Eventos [53,54 e 57]

são essenciais, porém quando existirem dados serão direcionados para elemento TYPE.event. Dúvida: usando os qualificadores, como separar dados como Nome, Data e País?

Dúvida 6: Campos de Indexação [71, 76, 87 e 88]

usam o mesmo elemento SUBJECT.descriptor. Ocorrerá o mesmo problema qdo ocorrer harvesting de dados por OAI? Será necessário escolher qual elemento coletar?

Dúvidas Gerais

Fábio Brito

Sueli bom dia!

Ontem na reunião de Dspace foi comentado pelo Mori que a Fiocruz migrou seus dados do LILDBI-Web para o Dspace. Pesquisei a princípio dois registros para conhecer os campos que foram utilizados e ver de que forma eles estão trabalhando com a questão do "de-para". Penso que podemos nos orientar bastante a partir da análise de como eles estão trabalhando com seus dados nos diversos tipos de documento.

Seguem dois link´s do Dspace da Fiocruz para análise: Registro de Tese Registro de Artigo

Fábio Brito

Fábio Brito: 2011-07-13

Fiz uma versão preliminar baseando-me no "de para" sugerido por Sueli ( http://wiki.bireme.org/pt/index.php/Metadados_m%C3%ADnimos_para_Artigos_de_Peri%C3%B3dicos_%28S_as%29 ). Esse "teste" de conversão tem alguns registros denominados S-as (Artigos) oriundos da base LILACS.

Para esse modelo criei apenas os campos dc.identifier.doi e dc.identifier.pmid pois no schema "padrão" não era contemplado.

Agradeço a sugestão dos colegas para melhorias no modelo abaixo.

De-Para (para registros S-as)
Campo DC Campo LILACS
dc.type [05] - Tipo de Literatura + [06] - Nivel de Tratamento + [09] - Tipo de Registro + [110] - Forma do Item + [113] - Tipo de Periodico
dc.contributor.author [10] - Autor Pessoal (nivel analitico)
dc.format.extent [03] paginas (analiticas) + [14] - paginas (nivel analitico) + [38] - Descricao Fisica
dc.title [12] - Titulo (nivel analitico)
dc.identifier.citation [30] - Titulo (nivel serie) + [31] - Volume (nivel serie) + [32] - Numero do Fasciculo (nivel serie)
dc.identifier.issn [35] - ISSN
dc.identifier.doi [724] - DOI
dc.identifier.pmid [2] Número de Identificação
dc.language.iso [40] - Idioma
dc.date.issued [64] - Data de Publicacao
dc.subject.other [71] - Tipo de Publicacao + [76] - Descritor Pre-codificado + [85] - Palavra-chave do autor + [87] - Descritor Primario + [88] - Descritor Secundario
dc.description.abstract [38] - Descricao Fisica
dc.date.accessioned [91] - Data da Criacao do Registro


Fábio Brito: 2011-07-13

Segue a sugestão para registros de Monografias (Mm). Nesse sugiro a criação dos campos dc.degree.date e dc.degree.local. Observando o que foi realizado pela FIOCRUZ ( http://wiki.reddes.bvsalud.org/img_auth.php/4/40/Campos_arca-lildbi.doc ) e também dc.identifier.pmid.

De-Para (para Monografias - Mm)
Campo DC Campo LILACS
dc.contributor.autor [16] Autor Pessoal - nível monográfico
dc.degree.date [64] Data de Publicação
dc.degree.local [66] Cidade de Publicação
dc.description.abstract [83] Resumo
dc.format.extent [38] Informação Descritiva
dc.identifier.pmid [2] Número de Identificação
dc.identifier.citation [20] Páginas - nível monográfico
dc.language.iso [40] Idioma do Texto
dc.subject.other [76] Descritor Pré-codificado + [87] Descritor Primário + [88] Descritor Secundário
dc.title [18] Título - nível monográfico
dc.type [5] Tipo de Literatura + [6] Nível de Tratamento

Elisabeth Biruel: 13/07/2011

PERGUNTA: Olá Sueli, Senti falta do campo de afiliação dos autores e dos países de publicação. Faria parte desta fase incluir estes campos?


RESPOSTA: Os subcampos de afiliação estão presentes e são essenciais em artigos de periódicos, ou seja, no campo 10 correspondem aos subcampos ^1^2e ^3 e os subcampos ^c e ^p correspondem a cidade e país.

Os dados de afiliação por enqto estão mapeados para:


Creator ou Contributor (conforme a dúvida que ainda persiste) elemento Affiliation, então ficaria assim:


dc.creator.personal name: Suga, Sueli Mitiko Yano

dc.creator.affiliation: ^1BIREME^2Produção de Fontes de Informação^3Fontes de Informação Referenciais


Com essa sua pergunta outra nova dúvida aparece, colocamos toda a descrição de afiliação nesse campo de forma normalizada? Se sim, então o resultado seria:


dc.creator.affiliation: ^1BIREME^2Produção de Fontes de Informação^3Fontes de Informação Referenciais^cSão Paulo^pBrasil


Outra forma poderia ser conforme a descrição feita no projeto ARCA da FioCruz, porém não está seguindo a Metodologia LILACS, mas vou apresentar como um outro exemplo:


dc.creator.affiliation: Bibliotecária do setor Fontes de Informação Referenciais, gerência Produção de Fontes de Informação da BIREME, São Paulo, Brasil.

Maria Cristina Soares: 14/07/2011

PERGUNTA: Sueli, verificando o Metadados mínimos para Artigos de Periódicos (S as) no wiki apenas uma dúvida mas quero ver com voce somente, pois de repente é algo simples que não entendi tem os campos 03 [03] páginas (analíticas) [14] - páginas (nível analítico) qual seria a diferença de ambos apenas esta dúvida, os demais campos estão claros.

RESPOSTA: é verdade Cris! Vou verificar, pois deve ter algo errado aí! BJsss e obrigada!

Algumas dúvidas by Fabrício Assumpção

Olá pessoal,

Meu nome Fabrício S. Assumpção, sou aluno do Curso de Biblioteconomia da Unesp, Campus de Marília. A Sueli divulgou o projeto que vocês estão realizando e pediu a colaboração do Grupo de Pesquisa Novas Tecnologias em Informação, do qual ela fez parte. Assim, a coordenadora do Grupo, a Profª Plácida Santos, pediu que eu colaborasse com o projeto de vocês.

Já troquei alguns e-mails com a Sueli, ela me explicou algumas coisas do Projeto e me encaminhou um material sobre a Metodologia LILACS.
Apresentei para ela algumas observações iniciais minhas e ela achou interessante que eu as postasse aqui na página de discussão, aí vão elas:

Pelo que entendi até agora, vocês estão planejando o harvesting de metadados em repositórios institucionais, os quais utilizam o DC.
Sendo assim, acredito que é necessário fazer também uma tabela "de DC para S as", junto com a tabela "de S as para DC" que está na página Metadados mínimos para Artigos de Periódicos (S as).
Assim o mapeamento dos metadados fica bidirecional (S as-DC e DC-S as), facilitando a criação da interface de interoperabilidade, ao mesmo tempo que permite visualizar se para todos os elementos do DC haverá um correspondente na "S as" e quantos serão os correspondentes, e vice-versa.

Estou com algumas dúvidas sobre o Dublin Core Qualified (DCQ). Li algumas coisas e tive a impressão de que o DCQ é um conjunto de elementos pré-estabelecidos que podem ser utilizados junto com os 15 elementos tradicionais. No entanto, vi na página de discussão exemplos (por exemplo esse: http://www.arca.fiocruz.br/handle/icict/1391?mode=full&submit_simple=Mostrar+registro+em+formato+completo) da utilização de elementos que eu não encontrei na lista dos elementos do DCQ. Por exemplo os elementos: dc.creator.affilliation, dc.journal.volume, entre outros. Vi as outras postagens na lista de discussão e percebi que a FIOCRUZ criou também outros elementos para atender suas próprias necessidades.

Aí me vieram algumas dúvidas:

  • Vocês instalaram (ou estalarão) um repositório DSpace para testar a interface de harvesting, não é?
  • Vocês estão customizando os formulários do DSpace para que seja possível coletar os metadados do DSpace e inseri-los em registros "S as", não é?
  • Para customizar os formulários vocês estão criando (ou criarão) alguns campos/elementos que não estão contemplados no DC nem no DCQ?

Assim, se eu entendi direito (desculpe-me se não entendi rsrs - isso tudo ainda é muito novo para mim), vocês estão criando algo que pode não tornar a interoperabilidade mais fácil, pois todos os repositórios dos quais vocês desejarem coletar os metadados terão que ter seus formulários customizados, contendo esses campos/elementos que vocês estão criando, o que pode complicar um pouco o trabalho de vocês, visto que nem todas as instituições estarão prontamente dispostas à alterar os formulários de seus repositórios.

Outro ponto em que tenho algumas inquietações, e que você abordou em seus slides, é a questão do "container dos dados" versus "valor" (como os dados estão registrados).
Esta deve ser a questão principal e é, consequentemente, a mais complicada, na minha opinião.
Não adianta muita coisa termos dados que foram registrados de acordo com instrumentos de descrição (regras, códigos, etc.) que são diferentes ou incompatíveis com os nossos.
Nesse ponto, acredito que as atuais ferramentas oferecidas pela Ciência da Computação permite a resolução de algumas incompatibilidades entre os dados, no entanto, em alguns casos penso que será necessária a ação humana.

Essa é uma questão a ser pensada, mas antes é necessário definir exatamente quais metadados serão importados e para quais campos desejamos que eles sejam registrados. Somente depois dessa fase poderemos dizer algo do tipo: "o dado X, inserido no campo Y do padrão Z, do provedor de serviços W é registrado de acordo com a instrução (regra, padrão, código) K; para coletarmos o dado X e inseri-lo no campo A do nosso banco de dados, é necessário fazer com que esse dado X fique registrado de acordo com nossas instruções/regras".

Bom, por enquanto acho que é isso.
Não sei se entendi exatamente, desculpe-me se cometi algum engano.
Ainda não tive tempo de me familiarizar com o Projeto!

Abraços, Fabrício Assumpção 21h18min de 15 de julho de 2011 (BRT)

Algumas respostas sobre as dúvidas do Fabrício

  • DSpace de teste: estamos trabalhando com uma instância de teste para o DSpace e cada membro do grupo tem um DSpace instalado em uma máquina virtual. Trabalhamos primeiro em nossa máquina virtual e depois carregamos os avanços na instância de teste. Acredito que o Fábio Brito já tenha carregado o formulário para entrada de dados para Artigos de periódicos baseado nesses metadados que propusemos.
  • Harvesting bidirecional: estamos validando a primeira versão de metadados para depois fazer a tabela bidirecional conforme já existe para MARC ([www.loc.gov/marc/marc2dc.html MARC 2 DC] e [www.loc.gov/marc/dccross.html DC 2 MARC], seria como o nosso Crosswalk.
  • Criação de novos elementos e qualificadores (qualifiers): Conforme pudemos ver no projeto ARCA, eles criaram ambos, mas nós planejamos não criar nenhum Elemento novo, somente qualificadores e especifidores de código. Ainda assim o faremos com base em iniciativas existentes de modo a evitar ao máximo criar campos totalmente novos, visto que muito já foi feito em outras iniciativas.
  • Criação de formulários: Sim, estamos criando formulários conforme os campos que estamos propondo, mas sabemos que teremos que interoperar com outras plataformas que seguirão, por exemplo, o DC Library Application Profile, e por isso também faremos um crosswalk com ele, visto que conforme minha apresentação, esse nível de entrada de dados, provavelmente poderá ser um registro LILACS.
  • Consistência e qualidade dos dados coletados: ainda não temos o documento pronto, mas o LILACS application profile servirá para isso, orientar qto aos elementos, qualifiers e códigos que utilizamos, bem como instruir quanto ao preenchimento de dados. Somente isso não irá garantir a qualidade do preenchimento, então acredito teremos que fazer testes de coleta para cada base para melhorar a destinação dos dados para os campos LILACS.

Em termos automáticos, em nosso software LILDBI-Web temos vários checks de consistência e esse é o maior entrave que temos em termos de dizer se o DSpace realmente poderia suportar a Metodologia LILACS, visto que se fôssemos falar somente em criação de campos e webservices do DeCS, isso seria possível, porém esses checks ainda não foram verificados.

Ainda temos revisão humana para dados muito básicos em nosso setor e provavelmente esse tipo de registro advindos de coleta provavelmente tb passarão por uma revisão mínima.

Bom, acredito que por enqto seja isso. Caso tenha mais algumas dúvidas, por favor me avise!

abs e muito obrigada Fabrício! Sueli Mitiko Yano Suga 18/07/11 Sueli.suga 15h38min de 19 de julho de 2011 (BRT)

Últimas modificações e definições

Definições:

  • [02] Número de identificação ==> identifier.uri
  • [08] Documento eletrônico ==> fileset (DSpace não usa elemento do DC. O texto completo está na tag fileset.

Dúvida:

  • [04] Base de dados ==> type ou identifier?

Reunião KMS, KMC e KMC/BIREME

  • v1: Código do Centro - OPS criou um qualificador novo - dc.source.centercode (necessidade de alterar o namespace para ops)
  • v4: Base de Dados - Preenchimento de acordo com a origem do serviço OAI-PMH
  • v6: Nível de tratamento - deve ser retirado olhando os qualificadores do campo dc.relation (isPartof)
  • v8: End. Eletrônico - identifier.uri
    • Tb havíamos utilizado esse campo, porém verificamos que no DSpace essa informação ia em outro campo e no identifier.uri, a url apresentada era dos metadados desse documento dentro do DSpace (lembro-me de ter conversado com a Katinha sobre isso).
  • v9: Tipo de Registro - ??? format.*
  • v110: Forma do Item - ???
  • v113: Tipo de Periódico - ???
  • v10: Autor Pessoal - dc.contributor.author - Cristiane verificará o mapeamento - corrigir porque creator não tem qualificador
  • v11: Autor Institucional - IRIS e REPO OPS utilizarão o v10 tanto para pessoal como para corporativo. Eliane verificará com Sandra a extensão dc.contributor.corporatename - corrigir porque creator não tem qualificador
    • Sarah poderá mostrar um documento excel no qual mapeei o local (site) de onde retirei esse uso dc.contributor.corporatename
  • v14: páginas - A informação está não estruturada dentro do campo relation (ispartof), junto com a informação da revista
    • Esse campo não foi considerado como metadado mínimo pq na Metodologia LILACS, qdo um documento tem URL, esse campo torna-se de preenchimento facultativo.
  • v30, v31 e v32: Título (nível série) - não é identifier.citation (como citar o documento). Essa informação está no qualificador ispartof do campo relation
    • O primeiro mapeamento que fizemos considerava o ispartof, mas como fizemos a comparação com outros exemplos, como Scielo (e não lembro se tb o SEARO), acabamos mudando para identifier.citation.
  • v87: Descritor Primário - ??? melhor utilizar o subject.other ou estender para subject.decs. Melhor não utilizar o subject.mesh, pois há a possibilidade de utilizar um termo do DeCS que não pertence ao Mesh.
    • Olá Renato, desculpe me meter, mas entrei agora só para dar uma olhadinha e ... acredito que seja subject.descriptor.decs (pq o DeCS estaria no nível do MeSH).

Is part of

http://dublincore.org/documents/dc-citation-guidelines/