Мета OpenCitations: методология

Таблица ссылок

• Аннотация и введение
• Сопутствующие работы
• Методология
• Данные и услуги
• Обсуждение
• Заключение, благодарности и ссылки

3. Методология

Мета OpenCitations заполняется из входных данных в формате CSV (т. е. в табличной форме). Этот выбор не случаен. Мы обнаружили, что данные, предоставляемые OpenCitations в формате CSV (например, из COCI (OpenCitations, 2022)) загружаются чаще по сравнению с теми же данными в более структурированных форматах (например, JSON Scholix и RDF N-Quads). Это связано с меньшим размером файла (по сравнению с N-Quads и Scholix) и, прежде всего, с более высокой читаемостью табличного формата для человека. Последнее является основной причиной того, что форматом ввода, принятым в OpenCitations Meta, является CSV, чтобы облегчить будущий краудсорсинг библиографических метаданных, полученных в результате кураторской деятельности человека (Heibi et al., 2019a).

Входная таблица OpenCitations Meta имеет одиннадцать столбцов, что соответствует линеаризации OCDM (Daquino et al., 2020): идентификатор, название, автор, редактор, дата публикации, место проведения, том, выпуск, страница, тип и издатель. Подробное описание структуры каждого поля см. в (Massari & Heibi, 2022).

После получения табличных данных CSV они сначала автоматически обрабатываются (шаг «Куратор»), а затем преобразуются в RDF на основе OCDM (шаг «Создатель»). Наконец, курируемые CSV и RDF сохраняются в виде файлов, а соответствующее тройное хранилище заполняется постепенно. На рис. 2 обобщается рабочий процесс.

3.1 Куратор: дедупликация, обогащение и исправление

Процесс курирования выполняет три основных действия для улучшения качества получаемых данных: дедупликацию, обогащение и коррекцию.

Подход, выбранный для дедупликации данных, основан исключительно на идентификаторах. Другими словами, два разных объекта считаются одинаковыми тогда и только тогда, когда оба имеют один и тот же идентификатор, например, DOI для статей, ORCID для людей, ISBN для книг и ISSN для мест публикации (например, журналов).

Различные ресурсы с одинаковым идентификатором объединяются по четкому правилу: (1) если ресурсы являются частью одного файла CSV, предпочтение отдается информации первого вхождения. Однако (2) если ресурс уже описан в тройном хранилище, предпочтение будет отдано информации в тройном хранилище. Другими словами, мы считаем информацию, хранящуюся в тройном хранилище, доверенной, и ее можно инкрементировать только за счет дополнительных данных, поступающих из источника CSV.

После дедупликации объекта ему присваивается новый постоянный внутренний идентификатор, называемый метаидентификатором OpenCitations (OMID). OMID имеет структуру [entity_type_abbreviation]/[supplier_prefix][sequential_number]. Например, первая когда-либо обработанная журнальная статья имеет OMID br/0601, где br — это аббревиатура «библиографический ресурс», а 060 соответствует префиксу поставщика, который указывает базу данных, к которой принадлежит библиографический ресурс (в данном случае OpenCitations). Мета). Наконец, 1 указывает, что этот OMID идентифицирует первый библиографический ресурс индекса, когда-либо записанный для этого префикса.

Точнее, префикс поставщика, используемый для OpenCitations Meta, — «06[1-9]*0», т.е. за «06» может следовать любое число, исключая ноль и «0» в конце. Например, «060», «0610» и «06230» являются допустимыми префиксами поставщика в OpenCitations Meta.

Объектами, которые подлежат дедупликации и впоследствии идентифицируются с помощью OMID, являются внешние идентификаторы (сокр. id), роли агентов (т. е. авторы, редакторы, издатели, сокр. ar), ответственные агенты (т. е. люди и организации, сокращенно ra), варианты ресурсов (т. е. страницы, сокращенно re), а также места проведения, тома и выпуски (которые все являются библиографическими ресурсами, сокращенно br). Тома и выпуски имеют OMID, поскольку к ним относятся как к первоклассным материалам, а не как к атрибутам статей. Это имеет то преимущество, что позволяет, например, искать статьи в конкретном выпуске, тома названного журнала или выпуски журналов, опубликованные в течение определенного периода времени. Напротив, заголовки и даты рассматриваются как буквальные значения, а не как сущности.

На рис. 3 показано дерево решений дедупликации. Учитывая входной объект и его идентификаторы, существует шесть возможных результатов:

1. Если у сущности нет идентификаторов или они не существуют в тройном хранилище, то для сущности создается новый OMID;

   
   

2. Если у объекта нет OMID и если один из его внешних идентификаторов уже связан с одним и только одним другим объектом, то два объекта объединяются и рассматриваются как один и тот же;

   
   

3. Если внешние идентификаторы объекта в CSV соединяют два или более объекта в тройном хранилище, которые до сих пор были разными, и в CSV не указан OMID, то возникает конфликт, который не может быть разрешен автоматически и потребует ручного вмешательства. Для этого конфликтного субъекта создан новый OMID. Например, в CSV одно и то же название журнала связано с двумя идентификаторами: issn:1588-2861 и issn:0138-9130; однако в тройном хранилище есть записи для двух отдельных объектов: одна с идентификатором issn:1588-2861, а другая с идентификатором issn:0138-9130, которые на самом деле относятся к одному и тому же объекту;

   
   

4. Если объект в CSV имеет OMID, который существует в тройном хранилище, а другие идентификаторы отсутствуют, то информация в тройном хранилище перезаписывает информацию в CSV. Затем тройной магазин обновляется только путем добавления недостающих данных. Другими словами, указание OMID для сущности в CSV — это способ обновить существующую сущность в OpenCitations Meta;

   
   

5. Если у объекта есть существующий OMID, а дополнительные идентификаторы связаны с другими объектами без OMID (в CSV) или с тем же OMID (в CSV или тройном хранилище), тогда объекты объединяются. Более того, информация в CSV перезаписывается информацией, уже доступной в тройном хранилище, а недостающие данные, присутствующие в CSV, затем добавляются в тройное хранилище;

   
   

6. Наконец, если внешние идентификаторы соединяют несколько сущностей в тройном хранилище с разными OMID, то возникает конфликт. В этом случае OMID, указанный в CSV, имеет приоритет, и объединяются только объекты с этим OMID.

Учитывая эти общие правила, три конкретных случая заслуживают особого внимания. Первая примечательная проблема касается порядка авторов и редакторов, который должен соблюдаться согласно OCDM. В случае слияния порядок, записанный при первом создании объекта, перезаписывает последующие, а любые новые авторы или редакторы добавляются в конец существующего списка, как показано на рис. 4.

Во-вторых, в контексте объединения двух библиографических ресурсов люди, участвующие в качестве авторов или редакторов без идентификатора, устраняются на основе их имени и фамилии.

Последний важный случай касается отношений сдерживания между статьями, выпусками, томами и местами проведения. Эта структура сохраняется в случае слияния, когда два тома или выпуска считаются одинаковыми, только если они имеют одинаковое значение, которое может быть последовательным номером (например, «Том 1») или произвольным именем (например, «Clin_Sect» ).

3.2 Куратор: проверка ошибок

После того как все объекты получили OMID, данные нормализуются, а ошибки, которые могут обрабатываться автоматически, исправляются. Все идентификаторы проверяются на основе их схемы идентификаторов — например, синтаксическая правильность номеров ISBN, ISSN и ORCID вычисляется с использованием специальных формул, приведенных в документации схемы идентификаторов. Однако семантическая корректность идентификаторов проверяется только для ORCID и DOI, что осуществляется с использованием открытых API для проверки их фактического существования – поскольку, например, можно создать ORCID, который синтаксически действителен, но на самом деле это не так. закреплен за человеком.

Все неоднозначные и альтернативные символы, используемые для пробелов (например, табуляция, неразрывный пробел, em-пробел), преобразуются в пробел (символ Unicode U+0020). Аналогично, неоднозначные символы дефисов внутри идентификаторов, страниц, томов, выпусков, авторов и редакторов (например, неразрывные дефисы, тире, знак минус) заменяются на дефис-минус (символ Юникода U+002D).

Что касается названий библиографических ресурсов (столбцы «Место проведения» и «Название»), каждое слово в названии пишется с заглавной буквы, за исключением тех, в которых прописные буквы (вероятно, это аббревиатуры, например «FaBiO» и «CiTO»). Однако это исключение не распространяется на названия, полностью написанные с заглавной буквы. Это же правило соблюдается и для авторов и редакторов, как отдельных лиц, так и организаций.

Даты анализируются с учетом как действительности формата на основе ISO 8601 (ГГГГММ-ДД) (Wolf & Wicksteed, 1997), так и значения (например, 30 февраля не является допустимой датой). При необходимости дата сокращается. Например, дата 2020-02-30 преобразуется в 2020-02, поскольку день данной даты недействителен. аналогично, 2020-27-12 будет усечено до 2020, поскольку месяц (и, следовательно, день) недействителен. Дата отбрасывается, если год недействителен (например, год больше 9999).

Исправление томов и номеров выпусков основано на многочисленных правилах, заслуживающих особого упоминания. В целом мы определили шесть классов ошибок, которые могут возникнуть, и каждый класс рассматривается соответствующим образом:

1. Номер тома и номер выпуска в одном и том же поле (например, «Том 35 № специальный 1»). Два значения разделяются и присваиваются соответствующему полю.

2. Ошибки префикса (например, «.38»). Префикс удален.

   
   

3. Ошибки суффикса (например, «19/»). Суффикс будет удален.

   
   

4. Ошибки кодировки (например, «5â\x80\x926», «38â39», «3???4»). Сохраняются только крайние числа, разделенные одним дефисом. Поэтому примеры исправлены на «5-6», «38-39» и «3-4» соответственно, поскольку «â\x80\x92», «â» и «???» являются неправильно закодированными дефисами.

   
   

5. Том классифицируется как выпуск (например, «Том 1» в поле «Выпуск»). Если шаблон тома найден в поле «Выпуск», а поле «Объем» пусто, содержимое перемещается в поле «Объем», а поле «Выпуск» устанавливается в нулевое значение. Однако если поле «выпуск» содержит шаблон объема, а поле «объем» содержит шаблон выпуска, эти два значения меняются местами.

   
   

6. Выпуск классифицируется как том (например, «Специальный выпуск 2» в поле «том»). Он обрабатывается так же, как и случай 5, но в обратном порядке.

Мы считали томами те образцы, которые содержат слова «оригинальная серия», «том», «объем» и «том» на других языках, например «том» на французском языке и «силт» на турецком языке. Например, «Оригинальная серия», «Том 1», «Том 71», «Том 1» и «Килт: 1» классифицируются как тома. Вместо этого мы считали выпусками те шаблоны, которые содержали слова «выпуск», «специальный выпуск» и «выпуск» на разных языках, например «horssérie» (специальный выпуск на французском языке) и «özelsayı» (специальный выпуск на турецком языке). Например, «выпуск 2», «спецвыпуск 2», «спецвыпуск «Городская морфология», «Озель Сайы 5» и «Hors-serie 5» классифицируются как выпуски.

Наконец, если значение одновременно недействительно по своему формату и недействительно из-за того, что оно находится в неправильном поле, такое значение сначала исправляется, а затем при необходимости перемещается в правильное поле.

После устранения неоднозначности, обогащения и исправления входных данных создается и сохраняется новый файл CSV. Этот файл представляет собой первый результат процесса (3а на рис. 2).

3.3 Создатель: семантическое картирование

На этом этапе данные моделируются в формате RDF после OCDM (Daquino et al., 2020). Эта онтология повторно использует объекты, определенные в онтологиях SPAR, для представления библиографических объектов (fabio:Expression), идентификаторов (datacite:Identifier), ролей агентов (pro:RoleInTime), ответственных агентов (foaf:Agent) и деталей формата публикации (fabio:Manifestation). . Роль агента (т. е. автора, редактора или издателя) используется в качестве посредника между библиографическим ресурсом и ответственным агентом, т. е. лицом или организацией. Этот подход помогает нам определить зависящие от времени и контекста роли и статусы, такие как порядок авторов (Peroni et al., 2012). На рис. 5 показаны связи между различными объектами через графическую структуру Graffoo (Falco et al., 2014).

Например, в OpenCitations Meta сущность с OMID omid:br/062601067530 имеет заголовок «Открытый доступ и онлайн-публикации: новый рубеж в сестринском деле?» (dcterms:title) и был опубликован 25 июля 2012 г. (prism:publicationDate). При использовании FRBR (Tillet, 2005) статья является окончательной опубликованной версией или выражением оригинальной работы (fabio:Expression), в качестве образца которой используется сущность omid:re/06260837633 (frbr:embodiment), то есть печатное издание, соответствующее страницам 1905-1908 годов тома журнала (prism:startingPage, prism:endingPage). Точнее, статья является частью (frbr:partOf) выпуска (fabio:JournalIssue) номер 9 (fabio:hasSequenceIdentifier), содержащегося в томе (fabio:JournalVolume) номер 68 журнала Journal Of Advanced Nursing (fabio:Journal). ).

Кроме того, человек (foaf:Agent) Гленн Хант (foaf:givenName, foaf:familyName) является первым автором (pro:RoleInTime) в контексте этой статьи (pro:isDocumentContextFor). Точно так же второй автор — Мишель Клири (pro:hasNext).

Наконец, в этой публикации есть мета-идентификатор OpenCitations (OMID) omid:id/062601093630 (datacite:hasIdentifier), объект типа datacite:Identifier. Он также имеет внешний идентификатор, который использует в качестве схемы идентификатора идентификатор цифрового объекта (DOI) (datacite:usesIdentifierScheme) и имеет буквальное значение «10.1111/j.1365-2648.2012.06023.x» (литерал:hasLiteralValue).

После завершения сопоставления полученные данные RDF можно сохранить (4a на рис. 2) и загрузить в тройное хранилище (4b на рис. 2).

3.4 Создатель: происхождение и отслеживание изменений

Помимо обработки метаданных, большое значение уделяется происхождению и отслеживанию изменений сущностей в OpenCitations Meta. Происхождение — это запись о том, кто обработал конкретный объект, создав, удалив, изменив или объединив его, когда это действие было выполнено и каков был первоисточник (Gil et al., 2010). Отслеживание этой информации имеет решающее значение для обеспечения надежности метаданных в OpenCitations Meta. Действительно, истинность утверждения в Интернете и семантической сети никогда не бывает абсолютной, и целостность должна оцениваться каждым приложением, обрабатывающим информацию, путем оценки ее контекста (Koivunen & Miller, 2001).

Однако, помимо хранения информации о происхождении, механизмы, позволяющие понять эволюцию объектов, имеют решающее значение при работе с такими видами деятельности, как упражнения по оценке исследований, когда изменения, вызванные исправлениями или неверными спецификациями, могут повлиять на общую оценку ученого, исследовательской группы или целое учреждение. Например, название учреждения может со временем измениться, и отражение этих изменений в базе данных «затрудняет идентификацию всех названий и подразделений учреждения без каких-либо знаний истории учреждения» (Pranckute, 2021). Этот сценарий можно предотвратить, отслеживая, как развивались данные в базе данных, что позволяет пользователям понимать такую динамику без доступа к внешним базовым знаниям. Насколько нам известно, ни одна другая семантическая база данных научных метаданных не отслеживает изменения и происхождение стандарта RDF 1.1.

Механизм происхождения, используемый OpenCitations, описывает первоначальный снимок создания для каждого хранимого объекта, за которым могут следовать другие снимки с подробным описанием изменения, слияния или удаления данных, каждый из которых отмечен своим номером снимка, как показано на рис. 6.

Что касается семантического представления, в научной литературе обсуждалась проблема моделирования происхождения (Sikos & Philp, 2020) и отслеживания изменений в RDF (Pelgrin et al., 2021). На сегодняшний день ни один общий стандарт не достигает обеих целей. По этой причине OpenCitations использует наиболее широко распространенные подходы, а именно именованные графы (Carroll et al., 2005), онтологию Provenance (Lebo et al., 2013) и Dublin Core (Board, 2020).

В частности, каждый снимок связан с предыдущим через предикат prov:wasDerivedFrom и связан с сущностью, которую он описывает, через prov:specializationOf. Кроме того, каждый снимок соответствует именованному графу, в котором описаны метаданные происхождения, а именно ответственный агент (prov:wasAttributedTo), основной источник (prov:hadPrimarySource), время генерации (prov:generatedAtTime) и, после создание дополнительного снимка, время аннулирования (prov:invalidatedAtTime). Каждый снимок также может быть представлен описанием происходящего на естественном языке (dcterms:description).

Кроме того, модель происхождения OCDM добавляет новый предикат oco:hasUpdateQuery, описанный в онтологии OpenCitations (Daquino & Peroni, 2019), который выражает разницу между двумя версиями объекта с помощью запроса SPARQL UPDATE. На рис. 7 модель представлена в виде диаграммы Graffoo.

Процесс дедупликации, описанный в разделе 3.1, применяется не только к текущему состоянию набора данных, но и ко всей его истории за счет применения механизма отслеживания изменений. Другими словами, если идентификатор можно отследить до объекта, удаленного из тройного хранилища, этот идентификатор будет связан с OMID удаленного объекта. Если удаление вызвано цепочкой слияний, приоритет имеет OMID результирующего объекта. Дополнительную информацию о методологии запросов с обходом времени см. в (Massari & Peroni, 2022). Более подробную информацию о программном интерфейсе для создания данных и отслеживания изменений в соответствии с онтологиями SPAR см. в (Persiani et al., 2022).