Meta de OpenCitations: Metodología

Tabla de enlaces

• Resumen e introducción
• Obras relacionadas
• Metodología
• Datos y servicios
• Discusión
• Conclusión, agradecimientos y referencias

3. Metodología

OpenCitations Meta se completa a partir de datos de entrada en formato CSV (es decir, en forma tabular). Esta elección no es casual. Hemos descubierto que los datos expuestos por OpenCitations en formato CSV (por ejemplo, de COCI (OpenCitations, 2022)) se descargan con más frecuencia, en comparación con los mismos datos en formatos más estructurados (es decir, JSON Scholix y RDF N-Quads). Esto se debe al menor tamaño del archivo (en comparación con N-Quads y Scholix) y, sobre todo, a la mayor legibilidad del formato tabular para un humano. Esta última es la razón principal por la que el formato de entrada adoptado por OpenCitations Meta es CSV, para facilitar el futuro crowdsourcing de metadatos bibliográficos de actividades curatoriales humanas (Heibi et al., 2019a).

La tabla de entrada de OpenCitations Meta tiene once columnas, correspondientes a una linealización del OCDM (Daquino et al., 2020): id, título, autor, editor, fecha de publicación, lugar, volumen, número, página, tipo y editorial. Para obtener una descripción detallada de cómo está estructurado cada campo, consulte (Massari & Heibi, 2022).

Una vez que se han adquirido los datos tabulares CSV, los datos primero se seleccionan automáticamente (paso del curador) y luego se convierten a RDF según el OCDM (paso del creador). Finalmente, el CSV y RDF seleccionados se almacenan como archivos, mientras que el almacén triple correspondiente se completa de forma incremental. La figura 2 resume el flujo de trabajo.

3.1 Curador: deduplicación, enriquecimiento y corrección

El proceso de curación realiza tres acciones principales para mejorar la calidad de los datos recibidos: deduplicación, enriquecimiento y corrección.

El enfoque elegido para la deduplicación de datos se basa estrictamente en identificadores. En otras palabras, dos entidades diferentes se consideran iguales si, y sólo si, ambas tienen el mismo identificador, por ejemplo, un DOI para artículos, un ORCID para personas, un ISBN para libros y un ISSN para lugares de publicación (por ejemplo, revistas).

Se fusionan diferentes recursos con el mismo identificador siguiendo una regla precisa: (1) si los recursos forman parte del mismo archivo CSV, se favorece la información de la primera aparición. Sin embargo, (2) si el recurso ya está descrito en el triplestore, se favorecerá la información en el triplestore. En otras palabras, consideramos que la información almacenada en el triplestore es confiable y solo puede incrementarse con datos adicionales provenientes de una fuente CSV.

Una vez que se deduplica una entidad, se le asigna un nuevo identificador interno permanente llamado OpenCitations Meta Identifier (OMID). El OMID tiene estructura [abreviatura_tipo_entidad]/[prefijo_proveedor][número_secuencial]. Por ejemplo, el primer artículo de revista procesado tiene OMID br/0601, donde br es la abreviatura de “recurso bibliográfico” y 060 corresponde al prefijo del proveedor, que indica la base de datos a la que pertenece el recurso bibliográfico (en este caso, OpenCitations Meta). Finalmente, 1 indica que este OMID identifica el primer recurso bibliográfico del índice jamás registrado para ese prefijo.

Más precisamente, el prefijo de proveedor utilizado para OpenCitations Meta es “06[1-9]*0”, es decir, “06” seguido opcionalmente de cualquier número excepto cero y un “0” al final. Por ejemplo, "060", "0610" y "06230" son prefijos de proveedor válidos en OpenCitations Meta.

Las entidades que están sujetas a deduplicación y posteriormente identificadas con un OMID son identificadores externos (abreviado id), roles de agente (es decir, autores, editores, editores, abreviado ar), agentes responsables (es decir, personas y organizaciones, abreviado ra), realizaciones de recursos (es decir, páginas, abreviatura re), y lugares, volúmenes y números (que son todos recursos bibliográficos, abreviatura br). Los volúmenes y números tienen OMID porque se los trata como ciudadanos de primera clase, no como atributos de artículos. Esto tiene la ventaja de permitir, por ejemplo, buscar artículos dentro de un número específico, los volúmenes de una revista determinada o números de revistas publicados dentro de un período de tiempo determinado. Por el contrario, los títulos y las fechas se tratan como valores literales, no como entidades.

La figura 3 ilustra el árbol de decisiones de deduplicación. Dada una entidad de entrada y sus identificadores, hay seis resultados posibles:

1. Si la entidad no tiene identificadores o no existen en el almacén triple, se crea un nuevo OMID para la entidad;

   
   

2. Si la entidad no tiene un OMID, y si uno de sus identificadores externos ya se ha asociado con una y sólo otra entidad, entonces las dos entidades se fusionan y se tratan como si fueran la misma;

   
   

3. Si los identificadores externos de la entidad en el CSV conectan dos o más entidades dentro del triplestore que hasta ahora habían sido distintas, y no se especifica ningún OMID en el CSV, entonces surge un conflicto que no se puede resolver automáticamente y requerirá intervención manual. Se acuña una nueva OMID para esta entidad conflictiva. Por ejemplo, en el CSV, el mismo nombre de revista está asociado con dos identificadores, issn:1588-2861 e issn:0138-9130; sin embargo, en el triplestore, hay entradas para dos entidades separadas, una con identificador issn:1588-2861 y la otra con identificador issn:0138-9130, que en realidad se refieren a la misma entidad;

   
   

4. Si una entidad en el CSV tiene un OMID que existe en el triplestore y no hay otros ID presentes, entonces la información en el triplestore sobrescribe la del CSV. Luego, el almacén triple se actualiza únicamente agregando los detalles que faltan. En otras palabras, especificar su OMID para una entidad en el CSV es una forma de actualizar una entidad existente dentro de OpenCitations Meta;

   
   

5. Si una entidad tiene un OMID existente y se asocian identificadores adicionales con otras entidades sin un OMID (en el CSV) o con el mismo OMID (en el CSV o triplestore), entonces las entidades se fusionan. Además, la información del CSV se sobrescribe con la que ya está disponible en el triplestore y los detalles faltantes presentes en el CSV se agregan al triplestore;

   
   

6. Finalmente, si identificadores externos conectan varias entidades en el triplestore con diferentes OMID, entonces surge un conflicto. En este caso, el OMID especificado en el CSV tiene prioridad y solo se fusionan las entidades con ese OMID.

Dadas estas reglas generales, tres casos particulares merecen especial atención. La primera cuestión destacable se refiere al orden de autores y editores, que debe mantenerse según la OCDM. En caso de una fusión, el orden registrado cuando se creó la entidad por primera vez sobrescribe los siguientes, y los nuevos autores o editores se agregan al final de la lista existente, como se muestra en la Fig. 4.

En segundo lugar, en el contexto de la fusión de dos recursos bibliográficos, las personas involucradas como autores o editores sin un identificador se eliminan la ambigüedad en función de su nombre y apellido.

El último caso significativo involucra la relación de contención entre artículos, números, volúmenes y lugares. Esta estructura se conserva en el caso de una fusión, donde dos volúmenes o números se consideran iguales sólo si tienen el mismo valor, que puede ser un número secuencial (por ejemplo, "Volumen 1") o un nombre arbitrario (por ejemplo, "Clin_Sect" ).

3.2 Curador: prueba de errores

Una vez que todas las entidades han obtenido un OMID, los datos se normalizan y se corrigen los errores que se pueden manejar automáticamente. Todos los identificadores se verifican en función de su esquema de identificador; por ejemplo, la corrección sintáctica de los ISBN, ISSN y ORCID se calcula utilizando fórmulas específicas proporcionadas por la documentación del esquema de identificador. Sin embargo, la corrección semántica de los identificadores se verifica solo para ORCID y DOI, lo cual se hace utilizando API abiertas para verificar su existencia real, ya que, por ejemplo, es posible producir un ORCID que sea válido sintácticamente, pero que en realidad no lo sea. asignado a una persona.

Todos los caracteres ambiguos y alternativos utilizados para los espacios (p. ej., tabulador, espacio sin separación, espacio em) se transforman en espacios (carácter Unicode U+0020). De manera similar, los caracteres ambiguos para guiones dentro de identificadores, páginas, volúmenes, números, autores y editores (por ejemplo, guiones continuos, guión, signo menos) se cambian a guión menos (carácter Unicode U+002D).

En cuanto a los títulos de recursos bibliográficos (columnas “lugar” y “título”), todas las palabras del título están en mayúscula excepto aquellas que contienen mayúsculas (que probablemente sean acrónimos, por ejemplo, “FaBiO” y “CiTO”). Esta excepción, sin embargo, no cubre el caso de títulos enteramente capitalizados. La misma regla se sigue también para los autores y editores, ya sean individuos u organizaciones.

Las fechas se analizan considerando tanto la validez del formato, basada en ISO 8601 (AAAAMM-DD) (Wolf & Wicksteed, 1997), como el valor (por ejemplo, el 30 de febrero no es una fecha válida). Cuando sea necesario, la fecha se trunca. Por ejemplo, la fecha 2020-02-30 se transforma en 2020-02 porque el día de la fecha indicada no es válido. de manera similar, 2020-27-12 se truncará a 2020 ya que el mes (y por lo tanto el día) no es válido. La fecha se descarta si el año no es válido (por ejemplo, un año mayor que 9999).

La corrección de números de volúmenes y números se basa en numerosas reglas que merecen una mención especial. En general, hemos identificado seis clases de errores que pueden ocurrir y cada clase diferente se aborda en consecuencia:

1. Número de volumen y número de edición en el mismo campo (por ejemplo, “Vol. 35 N° spécial 1”). Los dos valores se separan y se asignan al campo correspondiente.

2. Errores de prefijo (por ejemplo, “.38”). Se elimina el prefijo.

   
   

3. Errores de sufijo (por ejemplo, “19/”). Se elimina el sufijo.

   
   

4. Errores de codificación (por ejemplo, “5â\x80\x926”, “38â39”, “3???4”). Sólo se conservan los números de los extremos, separados por un solo guión. Por lo tanto, los ejemplos se corrigen a “5-6”, “38-39” y “3-4”, respectivamente, ya que “â\x80\x92”, “â” y “???” son guiones codificados incorrectamente.

   
   

5. Volumen clasificado como emisión (por ejemplo, “Volumen 1” en el campo “edición”). Si el patrón de volumen se encuentra en el campo "problema" y el campo "volumen" está vacío, el contenido se mueve al campo "volumen" y el campo "problema" se establece en nulo. Sin embargo, si el campo "problema" contiene un patrón de volumen y el campo "volumen" contiene un patrón de problema, los dos valores se intercambian.

   
   

6. Número clasificado como volumen (por ejemplo, “Número especial 2” en el campo “volumen”). Se maneja de la misma manera que el caso 5, pero en roles invertidos.

Consideramos volúmenes aquellos patrones que contienen las palabras “serie original”, “volumen”, “vol” y volumen en varios otros idiomas, por ejemplo, “tome” en francés y “cilt” en turco. Por ejemplo, “Serie original”, “Volumen 1”, “Vol 71”, “Tomo 1” y “Cilt: 1” se clasifican como volúmenes. En cambio, consideramos como números aquellos patrones que contienen las palabras “número”, “número especial” y número en varios idiomas, por ejemplo, “horssérie” (número especial en francés) y “özel sayı” (número especial en turco). Por ejemplo, “número 2”, “número especial 2”, “número especial 'Morfología urbana”', “Özel Sayı 5” y “Hors-série 5” se clasifican como números.

Finalmente, en caso de que un valor no sea válido en su formato y no sea válido porque está en el campo incorrecto, dicho valor primero se corrige y luego se mueve al campo correcto, si corresponde.

Una vez que los datos de entrada han sido desambiguados, enriquecidos y corregidos, se produce y almacena un nuevo archivo CSV. Este archivo representa el primer resultado del proceso (3a en la Fig. 2).

3.3 Creador: mapeo semántico

En esta fase los datos se modelan en RDF siguiendo el OCDM (Daquino et al., 2020). Esta ontología reutiliza entidades definidas en las Ontologías SPAR para representar entidades bibliográficas (fabio:Expression), identificadores (datacite:Identifier), roles de agente (pro:RoleInTime), agentes responsables (foaf:Agent) y detalles del formato de publicación (fabio:Manifestation). . El rol del agente (es decir, autor, editor o editor) se utiliza como intermediario entre el recurso bibliográfico y el agente responsable, es decir, la persona u organización. Este enfoque nos ayuda a definir roles y estados que dependen del tiempo y del contexto, como el orden de los autores (Peroni et al., 2012). La Fig. 5 representa las relaciones entre las diversas entidades a través del marco gráfico Graffoo (Falco et al., 2014).

Por ejemplo, en OpenCitations Meta la entidad con OMID omid:br/062601067530 tiene el título Acceso abierto y publicación en línea: ¿una nueva frontera en enfermería? (dcterms:título) y se publicó el 25 de julio de 2012 (prisma: fecha de publicación). Usando FRBR (Tillett, 2005), el artículo es la versión final publicada, o una expresión del trabajo original (fabio:Expression), que tiene como muestra la entidad omid:re/06260837633 (frbr:embodiment), es decir la publicación impresa correspondiente a las páginas 1905-1908 del volumen de la revista (prisma:páginainicial, prisma:páginafinal). Más precisamente, el artículo forma parte (frbr:partOf) del número (fabio:JournalIssue) número 9 (fabio:hasSequenceIdentifier), contenido en el volumen (fabio:JournalVolume) número 68 de la sede Journal Of Advanced Nursing (fabio:Journal ).

Además, la persona (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) es el primer autor (pro:RoleInTime) en el contexto de este artículo (pro:isDocumentContextFor). Del mismo modo, la segunda autora es Michelle Cleary (pro:hasNext).

Finalmente, esta publicación tiene el Metaidentificador de OpenCitations (OMID) omid:id/062601093630 (datacite:hasIdentifier), una entidad de tipo datacite:Identifier. También cuenta con un identificador externo, que utiliza como esquema de identificación un Identificador de Objeto Digital (DOI) (datacite:usesIdentifierScheme) y que tiene el valor literal “10.1111/j.1365- 2648.2012.06023.x” (literal:hasLiteralValue).

Una vez que se completa el mapeo, los datos RDF producidos se pueden almacenar (4a en la Fig. 2) y cargar en un almacén triple (4b en la Fig. 2).

3.4 Creador: procedencia y seguimiento de cambios

Además de manejar sus metadatos, se le da gran importancia a la procedencia y al seguimiento de cambios de las entidades en OpenCitations Meta. La procedencia es un registro de quién procesó una entidad específica creándola, eliminándola, modificándola o fusionándola, cuándo se realizó esta acción y cuál fue la fuente principal (Gil et al., 2010). Realizar un seguimiento de esta información es crucial para garantizar la confiabilidad de los metadatos dentro de OpenCitations Meta. De hecho, la verdad de una afirmación en la Web y la Web Semántica nunca es absoluta, y la integridad debe ser evaluada por cada aplicación que procese información evaluando su contexto (Koivunen & Miller, 2001).

Sin embargo, además de almacenar información sobre la procedencia, los mecanismos para comprender la evolución de las entidades son fundamentales cuando se trata de actividades como ejercicios de evaluación de investigaciones, donde las modificaciones, ya sea debido a correcciones o especificaciones erróneas, pueden afectar la evaluación general de un académico, un grupo de investigación o toda una institución. Por ejemplo, el nombre de una institución puede cambiar con el tiempo, y el reflejo de estos cambios en una base de datos “hace difícil identificar todos los nombres y unidades de la institución sin ningún conocimiento de la historia de la institución” (Pranckut˙e, 2021). Este escenario se puede prevenir haciendo un seguimiento de cómo evolucionaron los datos en la base de datos, permitiendo así a los usuarios comprender dicha dinámica sin acceder a conocimientos previos externos. Hasta donde sabemos, ninguna otra base de datos semántica de metadatos académicos realiza un seguimiento de los cambios y la procedencia en el estándar RDF 1.1.

El mecanismo de procedencia empleado por OpenCitations describe una instantánea de creación inicial para cada entidad almacenada, potencialmente seguida de otras instantáneas que detallan la modificación, combinación o eliminación de datos, cada una marcada con su número de instantánea, como se resume en la Fig. 6.

En cuanto a la representación semántica, el problema del modelado de procedencia (Sikos & Philp, 2020) y el seguimiento de cambios en RDF (Pelgrin et al., 2021) se ha discutido en la literatura académica. Hasta la fecha, ningún estándar compartido logra ambos propósitos. Por esta razón, OpenCitations emplea los enfoques más compartidos, es decir, gráficos con nombre (Carroll et al., 2005), Provenance Ontology (Lebo et al., 2013) y Dublin Core (Board, 2020).

En particular, cada instantánea está conectada a la anterior a través del predicado prov:wasDerivedFrom y está vinculada a la entidad que describe a través de prov:specializationOf. Además, cada instantánea corresponde a un gráfico con nombre en el que se describen los metadatos de procedencia, es decir, el agente responsable (prov:wasAttributedTo), la fuente principal (prov:hadPrimarySource), el tiempo de generación (prov:generatedAtTime) y, después de la generación de una instantánea adicional, el tiempo de invalidación (prov:invalidatedAtTime). Opcionalmente, cada instantánea también puede representarse mediante una descripción en lenguaje natural de lo que sucedió (dcterms:description).

Además, el modelo de procedencia OCDM agrega un nuevo predicado, oco:hasUpdateQuery, descrito en la ontología OpenCitations (Daquino & Peroni, 2019), que expresa el delta entre dos versiones de una entidad a través de una consulta SPARQL UPDATE. La Fig. 7 muestra el modelo mediante un diagrama de Graffoo.

El proceso de deduplicación descrito en la Sección 3.1 se lleva a cabo no solo en el estado actual del conjunto de datos sino en todo su historial al aplicar el mecanismo de seguimiento de cambios. En otras palabras, si se puede rastrear un identificador hasta una entidad eliminada del triplestore, ese identificador se asociará con el OMID de la entidad eliminada. Si la eliminación se debe a una cadena de fusión, el OMID de la entidad resultante tiene prioridad. Para obtener más información sobre la metodología de consultas de recorrido temporal, consulte (Massari & Peroni, 2022). Para más detalles sobre la interfaz de programación para la creación de datos y seguimiento de cambios según las Ontologías SPAR, consultar (Persiani et al., 2022).