OpenCites Meta: Phương pháp luận

tác giả: (1) Arcangelo Massari, Trung tâm Nghiên cứu Siêu dữ liệu Học thuật Mở, Khoa Ngữ văn Cổ điển và Nghiên cứu Ý, Đại học Bologna, Bologna, Ý {arcangelo.massari@unibo.it}; (2) Fabio Mariani, Viện Triết học và Khoa học Nghệ thuật, Đại học Leuphana, Lüneburg, Đức {fabio.mariani@leuphana.de}; (3) Ivan Heibi, Trung tâm Nghiên cứu Siêu dữ liệu Học thuật Mở, Khoa Ngữ văn Cổ điển và Nghiên cứu Ý, Đại học Bologna, Bologna, Ý và Trung tâm Nghiên cứu Tiên tiến về Nhân văn Kỹ thuật số (/DH.arc), Khoa Ngữ văn Cổ điển và Nghiên cứu Ý, Đại học của Bologna, Bologna, Ý {ivan.heibi2@unibo.it}; (4) Silvio Peroni, Trung tâm Nghiên cứu Siêu dữ liệu Học thuật Mở, Khoa Ngữ văn Cổ điển và Nghiên cứu Ý, Đại học Bologna, Bologna, Ý và Trung tâm Nghiên cứu Tiên tiến về Nhân văn Kỹ thuật số (/DH.arc), Khoa Ngữ văn Cổ điển và Nghiên cứu Ý, Đại học của Bologna, Bologna, Ý {silvio.peroni@unibo.it}; (5) David Shotton, Trung tâm nghiên cứu điện tử Oxford, Đại học Oxford, Oxford, Vương quốc Anh {david.shotton@opencites.net}. Bảng liên kết Tóm tắt và giới thiệu Tác phẩm liên quan Phương pháp luận Dữ liệu và dịch vụ Cuộc thảo luận Kết luận, Lời cảm ơn và Tài liệu tham khảo 3. Phương pháp luận OpenCites Meta được điền từ dữ liệu đầu vào ở định dạng CSV (tức là dạng bảng). Sự lựa chọn này không phải là ngẫu nhiên. Chúng tôi nhận thấy rằng dữ liệu do OpenCites cung cấp ở định dạng CSV (ví dụ: từ COCI (OpenCites, 2022)) được tải xuống thường xuyên hơn so với cùng một dữ liệu ở các định dạng có cấu trúc chặt chẽ hơn (ví dụ: JSON Scholix và RDF N-Quads). Điều này là do kích thước tệp nhỏ hơn (so với N-Quads và Scholix) và trên hết là do con người có khả năng đọc định dạng dạng bảng cao hơn. Lý do thứ hai là lý do chính tại sao định dạng đầu vào được OpenCites Meta áp dụng là CSV, để tạo điều kiện thuận lợi cho việc cung cấp siêu dữ liệu thư mục trong tương lai từ các hoạt động giám tuyển của con người (Heibi et al., 2019a). Bảng đầu vào của OpenCites Meta có 11 cột, tương ứng với sự tuyến tính hóa của OCDM (Daquino và cộng sự, 2020): id, tiêu đề, tác giả, người biên tập, ngày xuất bản, địa điểm, tập, số phát hành, trang, loại và nhà xuất bản. Để biết mô tả chi tiết về cách cấu trúc của từng lĩnh vực, vui lòng xem (Massari & Heibi, 2022). Sau khi đã thu thập được dữ liệu dạng bảng CSV, trước tiên, dữ liệu sẽ được tự động quản lý (bước của Người quản lý) và sau đó được chuyển đổi sang RDF dựa trên OCDM (Bước của Người tạo). Cuối cùng, CSV và RDF đã tuyển chọn được lưu trữ dưới dạng tệp, trong khi kho lưu trữ ba tương ứng được điền tăng dần. Hình 2 tóm tắt quy trình làm việc. 3.1 Người quản lý: loại bỏ trùng lặp, làm giàu và sửa lỗi Quá trình giám tuyển thực hiện ba hành động chính để cải thiện chất lượng dữ liệu nhận được: loại bỏ trùng lặp, làm giàu và hiệu chỉnh. Cách tiếp cận được chọn để loại bỏ trùng lặp dữ liệu hoàn toàn dựa trên số nhận dạng. Nói cách khác, hai thực thể khác nhau được coi là giống nhau khi và chỉ khi cả hai đều có cùng mã định danh, ví dụ: DOI cho bài viết, ORCID cho người, ISBN cho sách và ISSN cho địa điểm xuất bản (ví dụ: tạp chí). Các tài nguyên khác nhau có cùng mã định danh được hợp nhất theo một quy tắc chính xác: (1) nếu các tài nguyên là một phần của cùng một tệp CSV, thì thông tin của lần xuất hiện đầu tiên sẽ được ưu tiên. Tuy nhiên, (2) nếu tài nguyên đã được mô tả trong bộ ba thì thông tin trong bộ ba sẽ được ưu tiên hơn. Nói cách khác, chúng tôi coi thông tin được lưu trữ trong triplestore là đáng tin cậy và thông tin này chỉ có thể tăng lên khi có dữ liệu bổ sung đến từ nguồn CSV. Khi một thực thể được loại bỏ trùng lặp, nó sẽ được gán một mã định danh nội bộ mới, vĩnh viễn được gọi là Mã định danh Meta OpenCites (OMID). OMID có cấu trúc [entity_type_abbreviation]/[supplier_prefix][sequential_number]. Ví dụ: bài báo đầu tiên từng được xử lý có OMID br/0601, trong đó br là tên viết tắt của “tài nguyên thư mục” và 060 tương ứng với tiền tố nhà cung cấp, cho biết cơ sở dữ liệu chứa tài nguyên thư mục (trong trường hợp này là OpenCites Meta). Cuối cùng, 1 chỉ ra rằng OMID này xác định tài nguyên thư mục đầu tiên của chỉ mục từng được ghi lại cho tiền tố đó. Chính xác hơn, tiền tố nhà cung cấp được sử dụng cho OpenCites Meta là “06[1-9]*0”, tức là “06” tùy chọn theo sau là bất kỳ số nào ngoại trừ số 0 và số “0” ở cuối. Ví dụ: “060”, “0610” và “06230” là tiền tố nhà cung cấp hợp lệ trong OpenCites Meta. Các thực thể chịu sự trùng lặp và sau đó được xác định bằng OMID là các mã định danh bên ngoài (abbr. id), vai trò tác nhân (tức là tác giả, biên tập viên, nhà xuất bản, abbr. ar), tác nhân chịu trách nhiệm (tức là các cá nhân và tổ chức, abbr. ra), các phương án tài nguyên (tức là các trang, abbr. re), và địa điểm, tập và số phát hành (tất cả đều là tài nguyên thư mục, abbr. br). Các tập và số phát hành có OMID vì chúng được coi là công dân hạng nhất chứ không phải thuộc tính của bài viết. Điều này có ưu điểm là cho phép người ta, chẳng hạn, tìm kiếm các bài báo trong một số báo cụ thể, số tập của một tạp chí có tên hoặc các số tạp chí được xuất bản trong một khoảng thời gian nhất định. Ngược lại, tiêu đề và ngày tháng được coi là giá trị bằng chữ, không phải là thực thể. Hình 3 minh họa cây quyết định loại bỏ trùng lặp. Với một thực thể đầu vào và các mã định danh của nó, có sáu kết quả có thể xảy ra: Nếu thực thể không có mã định danh hoặc chúng không tồn tại trong bộ ba thì một OMID mới sẽ được tạo cho thực thể đó; Nếu thực thể không có OMID và nếu một trong các mã định danh bên ngoài của nó đã được liên kết với một và chỉ một thực thể khác thì hai thực thể đó sẽ được hợp nhất và được coi là giống nhau; Nếu số nhận dạng bên ngoài của thực thể trong CSV kết nối hai hoặc nhiều thực thể trong bộ ba vốn đã khác biệt cho đến nay và không có OMID nào được chỉ định trong CSV thì sẽ xảy ra xung đột không thể giải quyết tự động và sẽ yêu cầu can thiệp thủ công. Một OMID mới được tạo ra cho thực thể xung đột này. Ví dụ: trong CSV, cùng một tên tạp chí được liên kết với hai mã định danh, issn:1588-2861 và issn:0138-9130; tuy nhiên, trong triplestore, có các mục nhập cho hai thực thể riêng biệt, một có mã định danh issn:1588-2861 và mục kia có mã định danh issn:0138-9130, trên thực tế đề cập đến cùng một thực thể; Nếu một thực thể trong CSV có OMID tồn tại trong triplestore và không có ID nào khác thì thông tin trong triplestore sẽ ghi đè thông tin đó trong CSV. Bộ ba sau đó chỉ được cập nhật bằng cách bổ sung các chi tiết còn thiếu. Nói cách khác, việc chỉ định OMID của nó cho một thực thể trong CSV là một cách để cập nhật một thực thể hiện có trong OpenCites Meta; Nếu một thực thể có OMID hiện có và các mã định danh bổ sung được liên kết với các thực thể khác không có OMID (trong CSV) hoặc có cùng OMID (trong CSV hoặc triplestore), thì các thực thể đó sẽ được hợp nhất. Hơn nữa, thông tin trong CSV bị ghi đè bằng thông tin đã có sẵn trong triplestore và các chi tiết bị thiếu trong CSV sau đó sẽ được thêm vào triplestore; Cuối cùng, nếu các mã định danh bên ngoài kết nối một số thực thể trong bộ ba với các OMID khác nhau thì sẽ xảy ra xung đột. Trong trường hợp này, OMID được chỉ định trong CSV được ưu tiên và chỉ các thực thể có OMID đó mới được hợp nhất. Với những quy tắc chung này, ba trường hợp cụ thể đáng được quan tâm đặc biệt. Vấn đề đáng chú ý đầu tiên liên quan đến thứ tự tác giả và biên tập viên phải được duy trì theo OCDM. Trong trường hợp hợp nhất, thứ tự được ghi khi thực thể được tạo lần đầu sẽ ghi đè những thực thể tiếp theo và mọi tác giả hoặc biên tập viên mới sẽ được thêm vào cuối danh sách hiện có, như minh họa trong Hình 4. Thứ hai, trong bối cảnh hai nguồn tài nguyên thư mục được hợp nhất, những người liên quan với tư cách là tác giả hoặc biên tập viên không có mã định danh sẽ được phân biệt dựa trên họ và tên của họ. Trường hợp quan trọng cuối cùng liên quan đến mối quan hệ ngăn chặn giữa các bài báo, số phát hành, tập và địa điểm. Cấu trúc này được giữ nguyên trong trường hợp hợp nhất, trong đó hai tập hoặc số phát hành chỉ được coi là giống nhau nếu chúng có cùng giá trị, có thể là số thứ tự (ví dụ: “Tập 1”) hoặc tên tùy ý (ví dụ: “Clin_Sect” ). 3.2 Người phụ trách: soát lỗi Khi tất cả các thực thể đã nhận được OMID, dữ liệu sẽ được chuẩn hóa và các lỗi có thể xử lý tự động sẽ được sửa. Tất cả các mã định danh đều được kiểm tra dựa trên sơ đồ định danh của chúng – ví dụ: tính chính xác về cú pháp của ISBN, ISSN và ORCID được tính toán bằng cách sử dụng các công thức cụ thể do tài liệu về lược đồ định danh cung cấp. Tuy nhiên, tính chính xác về mặt ngữ nghĩa của số nhận dạng chỉ được xác minh đối với ORCID và DOI, được thực hiện bằng cách sử dụng API mở để xác minh sự tồn tại thực tế của chúng - chẳng hạn, vì có thể tạo ORCID hợp lệ về mặt cú pháp nhưng thực tế không phải vậy được giao cho một người. Tất cả các ký tự mơ hồ và thay thế được sử dụng cho khoảng trắng (ví dụ: tab, dấu cách không ngắt, dấu cách em) đều được chuyển thành khoảng trắng (ký tự Unicode U+0020). Tương tự, các ký tự không rõ ràng cho dấu gạch nối trong id, trang, tập, số phát hành, tác giả và người biên tập (ví dụ: dấu gạch nối không ngắt, dấu gạch ngang, dấu trừ) được thay đổi thành dấu gạch ngang (ký tự Unicode U+002D). Về tiêu đề của nguồn thư mục (cột “địa điểm” và “tiêu đề”), mọi từ trong tiêu đề đều được viết hoa ngoại trừ những từ có chữ in hoa bên trong (có thể là từ viết tắt, ví dụ: “FaBiO” và “CiTO”). Tuy nhiên, ngoại lệ này không bao gồm trường hợp tiêu đề được viết hoa hoàn toàn. Quy tắc tương tự cũng được tuân theo đối với các tác giả và biên tập viên, dù là cá nhân hay tổ chức. Ngày được phân tích cú pháp xem xét cả tính hợp lệ của định dạng, dựa trên ISO 8601 (YYYYMM-DD) (Wolf & Wicksteed, 1997) và giá trị (ví dụ: ngày 30 tháng 2 không phải là ngày hợp lệ). Khi cần thiết, ngày sẽ bị cắt ngắn. Ví dụ: ngày 2020-02-30 được chuyển thành 2020-02 vì ngày của ngày đã cho không hợp lệ. tương tự, ngày 27-12 năm 2020 sẽ bị rút ngắn thành năm 2020 vì tháng (và do đó là ngày) không hợp lệ. Ngày bị loại bỏ nếu năm không hợp lệ (ví dụ: năm lớn hơn 9999). Việc điều chỉnh số lượng và số phát hành dựa trên nhiều quy tắc đáng được đề cập đặc biệt. Nói chung, chúng tôi đã xác định được sáu loại lỗi có thể xảy ra và mỗi loại khác nhau sẽ được xử lý tương ứng: Số tập và số phát hành trong cùng một trường (ví dụ: “Tập 35 N° đặc biệt 1”). Hai giá trị được tách ra và gán cho trường tương ứng. Lỗi tiền tố (ví dụ: “.38”). Tiền tố bị xóa. Lỗi hậu tố (ví dụ: “19/”). Hậu tố đã bị xóa. Lỗi mã hóa (ví dụ: “5â\x80\x926”, “38â39”, “3???4”). Chỉ những số ở cực trị được giữ lại, cách nhau bằng một dấu gạch nối. Do đó, các ví dụ được sửa thành “5-6”, “38-39” và “3-4”, vì “â\x80\x92”, “â” và “???” là các dấu gạch nối được mã hóa không chính xác. Tập được phân loại là vấn đề (ví dụ: “Tập 1” trong trường “vấn đề”). Nếu mẫu âm lượng được tìm thấy trong trường “vấn đề” và trường “âm lượng” trống thì nội dung sẽ được chuyển sang trường “âm lượng” và trường “vấn đề” được đặt thành rỗng. Tuy nhiên, nếu trường “vấn đề” chứa mẫu khối lượng và trường “khối lượng” chứa mẫu vấn đề thì hai giá trị sẽ được hoán đổi. Số phát hành được phân loại theo số lượng (ví dụ: “Số đặc biệt 2” trong trường “số lượng”). Nó được xử lý theo cách tương tự như trường hợp 5, nhưng với vai trò đảo ngược. Chúng tôi coi các mẫu có chứa các từ “bộ sách gốc”, “tập”, “tập” và tập bằng nhiều ngôn ngữ khác là tập, ví dụ: “tome” trong tiếng Pháp và “cilt” trong tiếng Thổ Nhĩ Kỳ. Ví dụ: “Original Series”, “Tập 1”, “Tập 71”, “Tome 1” và “Cilt: 1” được phân loại là tập. Thay vào đó, chúng tôi coi những mẫu có chứa các từ “vấn đề”, “số đặc biệt” và số phát hành bằng nhiều ngôn ngữ khác nhau, ví dụ như “horssérie” (số đặc biệt bằng tiếng Pháp) và “özel sayı” (số đặc biệt bằng tiếng Thổ Nhĩ Kỳ) là vấn đề. Ví dụ: “số 2”, “số đặc biệt 2”, “số đặc biệt 'Hình thái đô thị”', “Özel Sayı 5” và “Hors-série 5” được phân loại là số phát hành. Cuối cùng, trong trường hợp một giá trị vừa không hợp lệ ở định dạng vừa không hợp lệ do nằm sai trường thì giá trị đó trước tiên sẽ được sửa và sau đó được chuyển sang trường bên phải, nếu thích hợp. Khi dữ liệu đầu vào đã được phân tách, làm phong phú và hiệu chỉnh, một tệp CSV mới sẽ được tạo và lưu trữ. Tệp này thể hiện đầu ra đầu tiên của quy trình (3a trong Hình 2). 3.3 Người tạo: ánh xạ ngữ nghĩa Trong giai đoạn này, dữ liệu được mô hình hóa trong RDF theo OCDM (Daquino và cộng sự, 2020). Bản thể luận này sử dụng lại các thực thể được xác định trong Bản thể luận SPAR để biểu diễn các thực thể thư mục (fabio:Expression), số nhận dạng (datacite:Identifier), vai trò tác nhân (pro:RoleInTime), tác nhân chịu trách nhiệm (foaf:Agent) và chi tiết định dạng xuất bản (fabio:Manifestation) . Vai trò đại diện (tức là tác giả, biên tập viên hoặc nhà xuất bản) được sử dụng như một ủy quyền giữa nguồn thư mục và đại lý chịu trách nhiệm, tức là cá nhân hoặc tổ chức. Cách tiếp cận này giúp chúng tôi xác định các vai trò và trạng thái phụ thuộc vào thời gian và bối cảnh, chẳng hạn như thứ tự của các tác giả (Peroni và cộng sự, 2012). Hình 5 mô tả mối quan hệ giữa các thực thể khác nhau thông qua khung đồ họa Graffoo (Falco và cộng sự, 2014). Ví dụ: trong OpenCites Meta, thực thể có OMID omid:br/062601067530 có tiêu đề Truy cập mở và xuất bản trực tuyến: Một biên giới mới trong điều dưỡng? (dcterms:title) và được xuất bản vào ngày 25-07-2012 (prism:publicationDate). Sử dụng FRBR (Tillett, 2005), bài viết là phiên bản được xuất bản cuối cùng, hoặc là một biểu hiện của tác phẩm gốc (fabio:Expression), có mẫu là thực thể omid:re/06260837633 (frbr:embodiment), tức là ấn phẩm in tương ứng với các trang 1905-1908 của tập tạp chí (prism:startingPage, prism:endingPage). Chính xác hơn, bài viết là một phần của (frbr:partOf) số (fabio:JournalIssue) số 9 (fabio:hasSequenceIdentifier), có trong tập (fabio:JournalVolume) số 68 của địa điểm Tạp chí Điều dưỡng nâng cao (fabio:Journal ). Hơn nữa, người (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) là tác giả đầu tiên (pro:RoleInTime) trong bối cảnh của bài viết này (pro:isDocumentContextFor). Tương tự, tác giả thứ hai là Michelle Cleary (pro:hasNext). Cuối cùng, ấn phẩm này có OpenCites Meta Identifier (OMID) omid:id/062601093630 (datacite:hasIdentifier), một thực thể thuộc loại datacite:Identifier. Nó cũng có một mã định danh bên ngoài, sử dụng làm sơ đồ định danh là Mã định danh đối tượng kỹ thuật số (DOI) (datacite:usesIdentifierScheme) và có giá trị bằng chữ “10.1111/j.1365- 2648.2012.06023.x” (nghĩa đen:hasLiteralValue). Sau khi ánh xạ hoàn tất, dữ liệu RDF được tạo ra có thể được lưu trữ (4a trong Hình 2) và tải lên bộ ba (4b trong Hình 2). 3.4 Người tạo: theo dõi xuất xứ và thay đổi Ngoài việc xử lý siêu dữ liệu của chúng, việc theo dõi nguồn gốc và thay đổi của các thực thể trong OpenCitations Meta còn rất quan trọng. Nguồn gốc là hồ sơ về người đã xử lý một thực thể cụ thể bằng cách tạo, xóa, sửa đổi hoặc hợp nhất nó, thời điểm hành động này được thực hiện và nguồn chính là gì (Gil et al., 2010). Việc theo dõi thông tin này là rất quan trọng để đảm bảo độ tin cậy của siêu dữ liệu trong OpenCites Meta. Thật vậy, sự thật của một tuyên bố trên Web và Web ngữ nghĩa không bao giờ là tuyệt đối và tính toàn vẹn phải được đánh giá bởi mọi ứng dụng xử lý thông tin bằng cách đánh giá bối cảnh của nó (Koivunen & Miller, 2001). Tuy nhiên, bên cạnh việc lưu trữ thông tin xuất xứ, các cơ chế để hiểu sự phát triển của các thực thể là rất quan trọng khi xử lý các hoạt động như thực hiện đánh giá nghiên cứu, trong đó các sửa đổi, do sửa chữa hoặc xác định sai, có thể ảnh hưởng đến đánh giá chung của học giả, nhóm nghiên cứu hoặc cả một cơ quan. Ví dụ: tên của một tổ chức có thể thay đổi theo thời gian và sự phản ánh của những thay đổi này trong cơ sở dữ liệu “gây khó khăn cho việc xác định tất cả tên và đơn vị của tổ chức nếu không có bất kỳ kiến thức nào về lịch sử của tổ chức” (Pranckut˙e, 2021). Tình huống này có thể được ngăn chặn bằng cách theo dõi cách dữ liệu phát triển trong cơ sở dữ liệu, từ đó cho phép người dùng hiểu được các động thái đó mà không cần truy cập kiến thức nền tảng bên ngoài. Theo hiểu biết của chúng tôi, không có cơ sở dữ liệu ngữ nghĩa nào của siêu dữ liệu học thuật theo dõi các thay đổi và nguồn gốc trong RDF 1.1 tiêu chuẩn. Cơ chế xuất xứ được OpenCites sử dụng mô tả ảnh chụp nhanh tạo ban đầu cho từng thực thể được lưu trữ, có thể theo sau là các ảnh chụp nhanh khác nêu chi tiết việc sửa đổi, hợp nhất hoặc xóa dữ liệu, mỗi ảnh chụp nhanh được đánh dấu bằng số ảnh chụp nhanh của nó, như được tóm tắt trong Hình 6. Về biểu diễn ngữ nghĩa, vấn đề mô hình hóa xuất xứ (Sikos & Philp, 2020) và theo dõi thay đổi trong RDF (Pelgrin và cộng sự, 2021) đã được thảo luận trong tài liệu học thuật. Cho đến nay, không có tiêu chuẩn chung nào đạt được cả hai mục đích. Vì lý do này, OpenCites sử dụng các cách tiếp cận được chia sẻ rộng rãi nhất, tức là các biểu đồ được đặt tên (Carroll và cộng sự, 2005), Bản thể luận chứng minh (Lebo và cộng sự, 2013) và Dublin Core (Board, 2020). Cụ thể, mỗi ảnh chụp nhanh được kết nối với ảnh chụp nhanh trước đó thông qua vị từ prov:wasDerivedFrom và được liên kết với thực thể mà nó mô tả thông qua prov:specializationOf. Ngoài ra, mỗi ảnh chụp nhanh tương ứng với một biểu đồ được đặt tên trong đó siêu dữ liệu xuất xứ được mô tả, cụ thể là tác nhân chịu trách nhiệm (prov:wasAttributionTo), nguồn chính (prov:hadPrimarySource), thời gian tạo (prov:generatedAtTime) và sau tạo một ảnh chụp nhanh bổ sung, thời gian vô hiệu (prov:invalidatedAtTime). Mỗi ảnh chụp nhanh cũng có thể được thể hiện tùy ý bằng một mô tả ngôn ngữ tự nhiên về những gì đã xảy ra (dcterms:description). Ngoài ra, mô hình xuất xứ OCDM còn thêm một biến vị ngữ mới, oco:hasUpdateQuery, được mô tả trong OpenCites Ontology (Daquino & Peroni, 2019), biểu thị delta giữa hai phiên bản của một thực thể thông qua truy vấn CẬP NHẬT SPARQL. Hình 7 hiển thị mô hình thông qua sơ đồ Graffoo. Quá trình loại bỏ trùng lặp được mô tả trong Phần 3.1 diễn ra không chỉ ở trạng thái hiện tại của tập dữ liệu mà còn trên toàn bộ lịch sử của nó bằng cách thực thi cơ chế theo dõi thay đổi. Nói cách khác, nếu một mã định danh có thể được truy nguyên về một thực thể đã bị xóa khỏi triplestore thì mã định danh đó sẽ được liên kết với OMID của thực thể đã xóa. Nếu việc xóa là do chuỗi hợp nhất thì OMID của thực thể kết quả sẽ được ưu tiên. Để biết thêm về phương pháp truy vấn truyền tải thời gian, hãy xem (Massari & Peroni, 2022). Để biết thêm chi tiết về giao diện lập trình để tạo dữ liệu và theo dõi các thay đổi theo Bản thể SPAR, hãy tham khảo ý kiến (Persiani et al., 2022). Bài viết này theo giấy phép CC 4.0 DEED. có sẵn trên arxiv