OpenCitations Meta: Metodologia

Tabela de Links

• Resumo e introdução
• Trabalhos relacionados
• Metodologia
• Dados e serviços
• Discussão
• Conclusão, agradecimentos e referências

3. Metodologia

OpenCitations Meta é preenchido a partir de dados de entrada em formato CSV (ou seja, formato tabular). Esta escolha não é acidental. Descobrimos que os dados expostos pelo OpenCitations em formato CSV (por exemplo, do COCI (OpenCitations, 2022)) são baixados com mais frequência, em comparação com os mesmos dados em formatos mais estruturados (por exemplo, JSON Scholix e RDF N-Quads). Isto se deve ao menor tamanho do arquivo (em comparação com N-Quads e Scholix) e, acima de tudo, à maior legibilidade do formato tabular para um ser humano. Esta última é a principal razão pela qual o formato de entrada adotado pelo OpenCitations Meta é CSV, para facilitar o futuro crowdsourcing de metadados bibliográficos de atividades curatoriais humanas (Heibi et al., 2019a).

A tabela de entrada do OpenCitations Meta possui onze colunas, correspondendo a uma linearização do OCDM (Daquino et al., 2020): id, título, autor, editor, data de publicação, local, volume, fascículo, página, tipo e editora. Para uma descrição detalhada de como cada campo está estruturado, consulte (Massari & Heibi, 2022).

Uma vez adquiridos os dados tabulares CSV, os dados são primeiro curados automaticamente (etapa Curador) e depois convertidos para RDF com base no OCDM (etapa Criador). Por fim, o CSV e o RDF selecionados são armazenados como arquivos, enquanto um triplestore correspondente é preenchido de forma incremental. A Figura 2 resume o fluxo de trabalho.

3.1 Curador: desduplicação, enriquecimento e correção

O processo de curadoria realiza três ações principais para melhorar a qualidade dos dados recebidos: desduplicação, enriquecimento e correção.

A abordagem escolhida para a desduplicação de dados baseia-se estritamente em identificadores. Em outras palavras, duas entidades diferentes são consideradas iguais se, e somente se, ambas tiverem o mesmo identificador, por exemplo, um DOI para artigos, um ORCID para pessoas, um ISBN para livros e um ISSN para locais de publicação (por exemplo, periódicos).

Diferentes recursos com o mesmo identificador são mesclados seguindo uma regra precisa: (1) se os recursos fizerem parte do mesmo arquivo CSV, a informação da primeira ocorrência é favorecida. Porém, (2) se o recurso já estiver descrito no triplestore, a informação no triplestore será favorecida. Em outras palavras, consideramos as informações armazenadas no triplestore como confiáveis, e só podem ser incrementadas com dados adicionais provenientes de uma fonte CSV.

Depois que uma entidade é desduplicada, é atribuído a ela um novo identificador interno permanente chamado OpenCitations Meta Identifier (OMID). O OMID possui estrutura [entity_type_abbreviation]/[supplier_prefix][sequential_number]. Por exemplo, o primeiro artigo de periódico já processado possui OMID br/0601, onde br é a abreviatura de “recurso bibliográfico”, e 060 corresponde ao prefixo do fornecedor, que indica a base de dados à qual pertence o recurso bibliográfico (neste caso, OpenCitations Meta). Finalmente, 1 indica que este OMID identifica o primeiro recurso bibliográfico do índice alguma vez registado para esse prefixo.

Mais precisamente, o prefixo do fornecedor usado para OpenCitations Meta é “06[1-9]*0”, ou seja, “06” opcionalmente seguido por qualquer número excluindo zero e um “0” no final. Por exemplo, “060”, “0610” e “06230” são prefixos de fornecedores válidos no OpenCitations Meta.

As entidades que estão sujeitas à desduplicação e posteriormente identificadas com um OMID são identificadores externos (abr. id), funções de agente (ou seja, autores, editores, editores, abr. ar), agentes responsáveis (ou seja, pessoas e organizações, abr. ra), incorporações de recursos (ou seja, páginas, abr. re) e locais, volumes e números (que são todos recursos bibliográficos, abr. br). Volumes e fascículos têm OMIDs porque são tratados como cidadãos de primeira classe, e não como atributos de artigos. Isto tem a vantagem de permitir, por exemplo, pesquisar artigos dentro de uma edição específica, os volumes de um periódico nomeado ou números de periódicos publicados dentro de um determinado período de tempo. Por outro lado, títulos e datas são tratados como valores literais, não como entidades.

A Figura 3 ilustra a árvore de decisão de desduplicação. Dada uma entidade de entrada e seus identificadores, existem seis resultados possíveis:

1. Caso a entidade não possua identificadores, ou estes não existam no triplestore, então é criado um novo OMID para a entidade;

   
   

2. Se a entidade não tiver um OMID, e se um dos seus identificadores externos já tiver sido associado a uma e apenas uma outra entidade, então as duas entidades são fundidas e tratadas como iguais;

   
   

3. Se os identificadores externos da entidade no CSV conectarem duas ou mais entidades dentro do triplestore que até então eram distintas, e nenhum OMID for especificado no CSV, surgirá um conflito que não poderá ser resolvido automaticamente e exigirá intervenção manual. Um novo OMID é cunhado para esta entidade conflitante. Por exemplo, no CSV, o mesmo nome de diário está associado a dois identificadores, issn:1588-2861 e issn:0138-9130; porém, no triplestore, existem entradas para duas entidades distintas, uma com identificador issn:1588-2861 e outra com identificador issn:0138-9130, que na realidade se referem à mesma entidade;

   
   

4. Se uma entidade no CSV tiver um OMID que existe no triplestore e nenhum outro ID estiver presente, as informações no triplestore substituirão as do CSV. O triplestore é então atualizado apenas pela adição de detalhes ausentes. Em outras palavras, especificar seu OMID para uma entidade no CSV é uma forma de atualizar uma entidade existente no OpenCitations Meta;

   
   

5. Se uma entidade tiver um OMID existente e identificadores adicionais estiverem associados a outras entidades sem um OMID (no CSV) ou com o mesmo OMID (no CSV ou no triplestore), as entidades serão mescladas. Além disso, as informações no CSV são substituídas pelas já disponíveis no triplestore, e os detalhes ausentes presentes no CSV são então adicionados ao triplestore;

   
   

6. Finalmente, se identificadores externos conectarem diversas entidades no triplestore com diferentes OMIDs, então surge um conflito. Neste caso, o OMID especificado no CSV tem precedência e apenas as entidades com esse OMID são mescladas.

Dadas estas regras gerais, três casos particulares merecem especial atenção. A primeira questão notável diz respeito à ordem dos autores e editores, que deve ser mantida de acordo com o OCDM. No caso de uma fusão, a ordem registrada quando a entidade foi criada pela primeira vez substitui as subsequentes, e quaisquer novos autores ou editores são adicionados ao final da lista existente, conforme mostrado na Figura 4.

Em segundo lugar, no contexto da fusão de dois recursos bibliográficos, as pessoas envolvidas como autores ou editores sem identificador são desambiguadas com base nos seus nomes próprios e de família.

O último caso significativo envolve a relação de contenção entre artigos, números, volumes e locais. Esta estrutura é preservada no caso de uma fusão, onde dois volumes ou fascículos são considerados iguais apenas se tiverem o mesmo valor, que pode ser um número sequencial (ex. “Volume 1”) ou um nome arbitrário (ex. “Clin_Sect” ).

3.2 Curador: à prova de erros

Depois que todas as entidades obtiverem um OMID, os dados são normalizados e os erros que podem ser tratados automaticamente são corrigidos. Todos os identificadores são verificados com base no seu esquema de identificação – por exemplo, a correção sintática de ISBNs, ISSNs e ORCIDs é calculada usando fórmulas específicas fornecidas pela documentação do esquema de identificadores. Porém, a correção semântica dos identificadores é verificada apenas para ORCIDs e DOIs, o que é feito utilizando APIs abertas para verificar sua real existência – já que, por exemplo, é possível produzir um ORCID que seja sintaticamente válido, mas que não o seja de fato. atribuído a uma pessoa.

Todos os caracteres ambíguos e alternativos usados para espaços (por exemplo, tabulação, espaço sem quebra, espaço em) são transformados em espaço (caractere Unicode U+0020). Da mesma forma, caracteres ambíguos para hífens em ids, páginas, volumes, números, autores e editores (por exemplo, hífens inseparáveis, travessão, sinal de menos) são alterados para hífen-menos (caractere Unicode U+002D).

Em relação aos títulos de recursos bibliográficos (colunas “local” e “título”), todas as palavras do título são maiúsculas, exceto aquelas com letras maiúsculas (que provavelmente são siglas, por exemplo, “FaBiO” e “CiTO”). Esta exceção, porém, não abrange o caso de títulos inteiramente maiúsculos. A mesma regra também é seguida para autores e editores, sejam eles indivíduos ou organizações.

As datas são analisadas considerando tanto a validade do formato, com base na ISO 8601 (AAAAMM-DD) (Wolf & Wicksteed, 1997), quanto o valor (por exemplo, 30 de fevereiro não é uma data válida). Quando necessário, a data é truncada. Por exemplo, a data 30/02/2020 é transformada em 02/2020 porque o dia da data especificada é inválido. da mesma forma, 2020-27-12 será truncado para 2020, pois o mês (e, portanto, o dia) é inválido. A data é descartada se o ano for inválido (por exemplo, um ano maior que 9999).

A correção de volumes e números de emissão baseia-se em inúmeras regras que merecem destaque especial. Em geral, identificamos seis classes de erros que podem ocorrer e cada classe diferente é tratada de acordo:

1. Número do volume e número do fascículo no mesmo campo (ex. “Vol. 35 N° spécial 1”). Os dois valores são separados e atribuídos ao campo correspondente.

2. Erros de prefixo (por exemplo, “.38”). O prefixo é excluído.

   
   

3. Erros de sufixo (por exemplo, “19/”). O sufixo é excluído.

   
   

4. Erros de codificação (por exemplo, “5â\x80\x926”, “38â39”, “3???4”). Apenas os números nos extremos são mantidos, separados por um único hífen. Portanto, os exemplos são corrigidos para “5-6”, “38-39” e “3-4”, respectivamente, já que “â\x80\x92”, “â” e “???” são hífens codificados incorretamente.

   
   

5. Volume classificado como fascículo (ex. “Volume 1” no campo “assunto”). Se o padrão de volume for encontrado no campo “problema” e o campo “volume” estiver vazio, o conteúdo será movido para o campo “volume” e o campo “problema” será definido como nulo. No entanto, se o campo “problema” contiver um padrão de volume e o campo “volume” contiver um padrão de problema, os dois valores serão trocados.

   
   

6. Emissão classificada como volume (ex. “Edição Especial 2” no campo “volume”). É tratado da mesma forma que o caso 5, mas em papéis invertidos.

Consideramos como volumes aqueles padrões contendo as palavras “série original”, “volume”, “vol” e volume em vários outros idiomas, por exemplo, “tome” em francês e “cilt” em turco. Por exemplo, “Série Original”, “Volume 1”, “Vol 71”, “Tomo 1” e “Cilt: 1” são classificados como volumes. Em vez disso, consideramos como questões os padrões que contêm as palavras “edição”, “edição especial” e edição em vários idiomas, por exemplo, “horssérie” (edição especial em francês) e “özel sayı” (edição especial em turco). Por exemplo, “edição 2”, “edição especial 2”, “edição especial 'Morfologia Urbana”', “Özel Sayı 5” e “Hors-série 5” são classificados como questões.

Finalmente, caso um valor seja inválido em seu formato e inválido porque está no campo errado, esse valor será primeiro corrigido e depois movido para o campo correto, se apropriado.

Uma vez desambiguados, enriquecidos e corrigidos os dados de entrada, um novo arquivo CSV é produzido e armazenado. Este arquivo representa a primeira saída do processo (3a na Fig. 2).

3.3 Criador: mapeamento semântico

Nesta fase, os dados são modelados em RDF seguindo o OCDM (Daquino et al., 2020). Esta ontologia reutiliza entidades definidas nas Ontologias SPAR para representar entidades bibliográficas (fabio:Expression), identificadores (datacite:Identifier), funções de agente (pro:RoleInTime), agentes responsáveis (foaf:Agent) e detalhes de formato de publicação (fabio:Manifestation). . A função do agente (ou seja, autor, editor ou editor) é usada como proxy entre o recurso bibliográfico e o agente responsável, ou seja, a pessoa ou organização. Essa abordagem nos ajuda a definir papéis e status dependentes do tempo e do contexto, como a ordem dos autores (Peroni et al., 2012). A Figura 5 mostra as relações entre as diversas entidades através da estrutura gráfica Graffoo (Falco et al., 2014).

Por exemplo, no OpenCitations Meta a entidade com OMID omid:br/062601067530 tem o título Open Access And Online Publishing: A New Frontier In Nursing? (dcterms:title) e foi publicado em 25/07/2012 (prism:publicationDate). Utilizando o FRBR (Tillett, 2005), o artigo é a versão final publicada, ou uma expressão do trabalho original (fabio:Expression), que tem como amostra a entidade omid:re/06260837633 (frbr:embodiment), que é o publicação impressa correspondente às páginas 1905-1908 do volume da revista (prism:startingPage, prism:endingPage). Mais precisamente, o artigo faz parte do (frbr:partOf) número (fabio:JournalIssue) número 9 (fabio:hasSequenceIdentifier), contido no volume (fabio:JournalVolume) número 68 da revista Journal Of Advanced Nursing (fabio:Journal ).

Além disso, a pessoa (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) é o primeiro autor (pro:RoleInTime) no contexto deste artigo (pro:isDocumentContextFor). Da mesma forma, a segunda autora é Michelle Cleary (pro:hasNext).

Por fim, esta publicação conta com o OpenCitations Meta Identifier (OMID) omid:id/062601093630 (datacite:hasIdentifier), uma entidade do tipo datacite:Identifier. Possui também um identificador externo, que utiliza como esquema identificador um Digital Object Identifier (DOI) (datacite:usesIdentifierScheme) e que possui o valor literal “10.1111/j.1365-2648.2012.06023.x” (literal:hasLiteralValue).

Uma vez concluído o mapeamento, os dados RDF produzidos podem ser armazenados (4a na Fig. 2) e carregados em um triplestore (4b na Fig. 2).

3.4 Criador: origem e rastreamento de alterações

Além de lidar com seus metadados, é dada grande importância à procedência e ao rastreamento de alterações para entidades no OpenCitations Meta. Proveniência é um registro de quem processou uma entidade específica ao criá-la, excluí-la, modificá-la ou fundi-la, quando essa ação foi realizada e qual foi a fonte primária (Gil et al., 2010). Manter o controle dessas informações é crucial para garantir a confiabilidade dos metadados no OpenCitations Meta. Na verdade, a verdade de uma declaração na Web e na Web Semântica nunca é absoluta, e a integridade deve ser avaliada por cada aplicação que processa informação, avaliando o seu contexto (Koivunen & Miller, 2001).

No entanto, além de armazenar informações de proveniência, mecanismos para compreender a evolução das entidades são críticos quando se trata de atividades como exercícios de avaliação de pesquisa, onde modificações, devido a correções ou especificações incorretas, podem afetar a avaliação geral de um acadêmico, de um grupo de pesquisa ou de um grupo de pesquisa. uma instituição inteira. Por exemplo, o nome de uma instituição pode mudar ao longo do tempo, e o reflexo destas mudanças numa base de dados “torna difícil a identificação de todos os nomes e unidades da instituição sem qualquer conhecimento da história da instituição” (Pranckut˙e, 2021). Este cenário pode ser evitado acompanhando a evolução dos dados no banco de dados, permitindo assim que os usuários entendam tal dinâmica sem acessar conhecimento prévio externo. Até onde sabemos, nenhum outro banco de dados semântico de metadados acadêmicos acompanha as mudanças e a origem no padrão RDF 1.1.

O mecanismo de proveniência empregado pelo OpenCitations descreve um instantâneo de criação inicial para cada entidade armazenada, potencialmente seguido por outros instantâneos detalhando modificação, mesclagem ou exclusão de dados, cada um marcado com seu número de instantâneo, conforme resumido na Figura 6.

Em relação à representação semântica, o problema da modelagem de proveniência (Sikos & Philp, 2020) e do rastreamento de mudanças em RDF (Pelgrin et al., 2021) tem sido discutido na literatura acadêmica. Até o momento, nenhum padrão compartilhado atinge ambos os propósitos. Por esta razão, OpenCitations emprega as abordagens mais amplamente partilhadas, ou seja, gráficos nomeados (Carroll et al., 2005), a Ontologia de Proveniência (Lebo et al., 2013) e Dublin Core (Board, 2020).

Em particular, cada instantâneo é conectado ao anterior por meio do predicado prov:wasDerivedFrom e vinculado à entidade que descreve por meio de prov:specializationOf. Além disso, cada snapshot corresponde a um grafo nomeado no qual são descritos os metadados de proveniência, nomeadamente o agente responsável (prov:wasAttributedTo), a fonte primária (prov:hadPrimarySource), o tempo de geração (prov:generatedAtTime) e, após o geração de um snapshot adicional, o tempo de invalidação (prov:invalidatedAtTime). Cada instantâneo também pode ser opcionalmente representado por uma descrição em linguagem natural do que aconteceu (dcterms:description).

Além disso, o modelo de proveniência OCDM adiciona um novo predicado, oco:hasUpdateQuery, descrito na OpenCitations Ontology (Daquino & Peroni, 2019), que expressa o delta entre duas versões de uma entidade por meio de uma consulta SPARQL UPDATE. A Figura 7 exibe o modelo através de um diagrama Graffoo.

O processo de desduplicação descrito na Seção 3.1 ocorre não apenas no estado atual do conjunto de dados, mas em todo o seu histórico, aplicando o mecanismo de rastreamento de alterações. Em outras palavras, se um identificador puder ser rastreado até uma entidade excluída do triplestore, esse identificador será associado ao OMID da entidade excluída. Se a exclusão for devido a uma cadeia de mesclagem, o OMID da entidade resultante terá precedência. Para mais informações sobre a metodologia de consultas de passagem no tempo, consulte (Massari & Peroni, 2022). Para mais detalhes sobre a interface de programação para criação de dados e acompanhamento de alterações conforme as Ontologias SPAR, consultar (Persiani et al., 2022).