DataCite API DOI metadata: đối soát creator và relatedIdentifier

DataCite API DOI metadata là cách lấy bản ghi metadata của DOI do DataCite quản lý, thường là dataset, phần mềm và tài liệu trong kho lưu trữ nghiên cứu, qua REST API công khai không cần khóa. Phần đáng giá nhất của bản ghi không phải tiêu đề mà là danh sách quan hệ tới DOI khác, và đây cũng là phần dễ đọc sai nhất. ProxyVN gọi API thật cho sáu DOI, chuẩn hóa creator và relatedIdentifiers, rồi kiểm từng quan hệ có được bên kia ghi ngược lại hay không.

DataCite API DOI metadata: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và ranh giới với bài Crossref.

Bài toán cần giải

Một nhóm nghiên cứu có danh sách DOI dataset lấy từ phần trích dẫn của nhiều bài báo. Họ muốn biết mỗi dataset do ai tạo, thuộc phiên bản nào, gắn với bài báo nào và có phải phiên bản mới nhất không. Đọc từng trang kho lưu trữ bằng tay mất nhiều ngày. API trả lời được, nếu đọc đúng.

Đầu ra nghiệm thu

Đầu ra là bảng dataset theo DOI gồm creator, ORCID, affiliation, loại tài nguyên, danh sách relatedIdentifier đã chuẩn hóa, và provenance của từng record: kho nào đăng ký, lúc nào, cập nhật mấy lần. Kèm theo là bảng cạnh quan hệ có cột cho biết bên kia có ghi quan hệ ngược không.

Ranh giới với bài Crossref

Blog đã có bài Crossref API bằng Python để đối soát DOI và ngày của bài báo. DataCite là một cơ quan đăng ký DOI khác, với schema và quy ước quan hệ riêng. Bài này không lặp lại cách gọi một DOI rồi đọc tiêu đề. Trọng tâm là relatedIdentifiers, phiên bản và provenance.

Không viết hai bài chỉ đổi tên miền

Cùng một chuỗi DOI có thể gửi tới cả hai API, nhưng chỉ một cơ quan có bản ghi gốc. Lab có một DOI của Crossref gửi tới DataCite và nhận 404. Phân biệt cơ quan đăng ký là bước đầu tiên, không phải chi tiết phụ.

Giới hạn của lab

Lab gọi API công khai thật ngày 05/11/2026, 27 lượt, cách nhau 1 giây, không dùng tài khoản thành viên. Bản ghi trên DataCite thay đổi theo thời gian, nhiều bản ghi trong lab vừa được tạo hoặc cập nhật trong ngày. Chạy lại vào ngày khác có thể ra số liệu khác.

Ai nên đọc

Người làm thư viện số, quản lý dữ liệu nghiên cứu hay đánh giá tác động cần ghép dataset với bài báo. Người viết pipeline thu metadata từ nhiều kho. Người đang dùng Crossref và muốn mở rộng sang dataset.

Lấy DataCite API DOI metadata và đối soát relation identifiers

Phần này tóm tắt những gì tài liệu chính thức nói và những gì cần cho phép thử.

API công khai và API thành viên

Tài liệu REST API của DataCite nói API chia hai phần dùng chung một địa chỉ api.datacite.org. API công khai không cần xác thực, dùng để đọc metadata. API thành viên cần tài khoản kho, dùng để tạo và sửa DOI, xem bản nháp và DOI chưa công bố.

Phiên bản API

Tài liệu ghi phiên bản hiện hành là version 2. Các endpoint như /works, /members và /data-centers thuộc version 1 và đã bị ngừng khuyến nghị. Lab chỉ dùng /dois và /dois/{doi}/activities của version 2.

Định dạng JSON:API

Response theo chuẩn JSON:API: phần data chứa id, type, attributes và relationships. Metadata nằm trong attributes. Kho đăng ký nằm trong relationships.client, tổ chức thành viên nằm trong relationships.provider. Mã đọc phải đi đúng các nhánh này.

User-Agent có liên hệ

Tài liệu khuyên script gọi API thường xuyên gửi User-Agent gồm tên script và địa chỉ liên hệ dạng mailto. Lab gửi ProxyVN-lab/1.0 kèm mô tả tần suất thấp. Pipeline thật của một nhóm nên thêm email liên hệ của nhóm vào User-Agent.

Môi trường test

Tài liệu nhắc có endpoint test là api.test.datacite.org cho việc tạo DOI thử. Đọc metadata thật thì dùng production. Lab chỉ đọc, không tạo hay sửa gì.

relatedIdentifiers là gì

Mỗi bản ghi có thể có danh sách relatedIdentifiers. Mỗi phần tử có relationType như IsVersionOf, relatedIdentifierType như DOI, URL, ISSN, và chuỗi định danh. Có khi kèm resourceTypeGeneral của đích. Đây là lời khai của bên tạo bản ghi, không phải liên kết đã được xác minh.

The REST API is split into two versions: a Public API and a Member API. (DataCite Support)

Schema metadata

Bản ghi DataCite theo DataCite Metadata Schema. Lab thấy schemaVersion là kernel-4 ở cả bốn bản ghi. Danh sách giá trị cho resourceTypeGeneral và relationType là danh sách đóng của schema, nên có thể kiểm giá trị lạ. Các trường tự do như resourceType hay tên affiliation thì không có danh sách nào để kiểm.

Khác Crossref ở đâu

Crossref chủ yếu quản lý DOI của bài báo, sách và hội nghị do nhà xuất bản đăng ký. DataCite chủ yếu quản lý DOI của dataset, phần mềm và tài liệu do kho lưu trữ, thư viện và trường đại học đăng ký. Hai bên có schema khác nhau, endpoint khác nhau và cách ghi quan hệ khác nhau.

Vì sao phải đối soát

Bên A khai quan hệ tới bên B không có nghĩa bên B khai lại. Với quan hệ phiên bản, kho thường ghi cả hai chiều. Với quan hệ bổ trợ hay trích dẫn, thường chỉ một bên ghi. Bảng đầu ra phải cho biết chiều nào có thật trong dữ liệu, chiều nào chỉ là suy luận.

Xác định DOI do DataCite quản lý và phiên bản API trong DataCite API DOI metadata

Bước này loại DOI không thuộc DataCite trước khi gọi API metadata.

Chuẩn hóa chuỗi đầu vào

Danh sách đầu vào có ba dạng: DOI trần, URL https://doi.org/ và tiền tố doi:. Lab bỏ tiền tố rồi chuyển về chữ thường. DOI không phân biệt hoa thường, nên ZENODO và zenodo là một. Chuỗi đã chuẩn hóa là khóa duy nhất trong mọi bảng.

def norm(doi):
    d = doi.strip()
    d = re.sub(r"^(https?://(dx\.)?doi\.org/|doi:)", "", d, flags=re.I)
    return d.lower()

Hỏi cơ quan đăng ký

Hỏi cơ quan đăng ký

Dịch vụ doi.org/ra/{doi} trả về cơ quan đăng ký của DOI. Lab gọi dịch vụ này cho từng DOI đầu vào. Bốn DOI của Zenodo và Dryad trả DataCite. DOI 10.1080/15487733.2025.2506199 trả Crossref. DOI bịa 10.5281/zenodo.0000000001 trả DOI does not exist.

Gửi DOI Crossref tới DataCite

Lab vẫn gửi DOI Crossref tới api.datacite.org để xem phản hồi. Kết quả là HTTP 404 với thông báo The resource you are looking for doesn't exist. Thông báo giống hệt DOI không tồn tại. Nếu không hỏi cơ quan đăng ký trước, hai trường hợp này không phân biệt được.

Tiền tố không đủ

Tiền tố 10.5281 là của Zenodo, 10.5061 là của Dryad, nhưng không nên dùng bảng tiền tố để đoán cơ quan. Một tổ chức có thể đổi cơ quan đăng ký, một tiền tố có thể chuyển chủ. Hỏi doi.org mất thêm một lượt gọi nhưng cho câu trả lời có nguồn.

Bảng đầu vào

Bảng: Bảng đầu vào

Đầu vào	DOI chuẩn hóa	Cơ quan	DataCite API
10.5281/zenodo.23977407	như cũ	DataCite	200
https://doi.org/10.5281/ZENODO.20742567	10.5281/zenodo.20742567	DataCite	200
doi:10.5061/dryad.j6q573nxg	10.5061/dryad.j6q573nxg	DataCite	200
10.5281/zenodo.23977456	như cũ	DataCite	200
10.1080/15487733.2025.2506199	như cũ	Crossref	404
10.5281/zenodo.0000000001	như cũ	không tồn tại	404

Gọi bằng requests

Mỗi lượt gọi đi qua một hàm get dùng chung: nghỉ 1 giây, gọi với timeout 30 giây, ghi URL, mã trạng thái, thời gian phản hồi và thời điểm vào nhật ký. Hàm này là chỗ duy nhất chạm mạng, nên đổi nhịp gọi hay thêm proxy chỉ cần sửa một nơi.

def get(url, **kw):
    time.sleep(1.0)
    t = time.time()
    r = S.get(url, timeout=30, **kw)
    LOG.append({"url": r.url, "status": r.status_code,
                "ms": round((time.time() - t) * 1000)})
    return r

Cách chọn DOI cho lab

Bốn DOI DataCite được chọn bằng một truy vấn tìm kiếm trên chính API, lọc dataset của Zenodo có quan hệ IsSupplementTo và dataset của Dryad có quan hệ IsCitedBy. Hai DOI của Zenodo là một cặp phiên bản. Cách chọn này đảm bảo có đủ loại quan hệ cần kiểm.

Tham số affiliation và publisher

Lab gọi /dois/{doi} với affiliation=true và publisher=true. Hai tham số này làm API trả affiliation và publisher dạng đối tượng có định danh, thay vì chỉ chuỗi tên. Nhờ vậy thấy được ROR ID của tổ chức khi kho có khai.

Lấy creator, types và relatedIdentifiers từ DataCite API DOI metadata

Phần này đọc từng nhóm trường từ bốn bản ghi lấy được.

Creator và ORCID

Bản ghi 10.5281/zenodo.23977407 có 5 creator, cả 5 đều có ORCID. Bản ghi Dryad có 7 creator, chỉ 2 có ORCID. Bản ghi 10.5281/zenodo.23977456 có 1 creator có ORCID. Không có ORCID nghĩa là không thể ghép tác giả bằng định danh, chỉ còn tên.

ORCID hai định dạng

Zenodo ghi ORCID dạng mã trần như 0009-0008-7077-1894. Dryad ghi dạng URL như https://orcid.org/0000-0002-8959-898X. Cùng trường nameIdentifier, hai kho, hai định dạng. Mã ghép tác giả phải chuẩn hóa về một dạng trước khi so, nếu không cùng một người sẽ thành hai.

Affiliation có và không có ROR

Trong bản ghi Zenodo, creator đầu có affiliation Institute for Economic Research kèm ROR https://ror.org/014z5x149. Creator thứ hai có Institute for Economic Research (IER) không có ROR. Creator thứ ba có Institute for Economic Research không có ROR. Ba cách ghi cho một tổ chức trong cùng bản ghi.

Publisher có định danh

Bản ghi Dryad có publisher là Dryad kèm publisherIdentifier https://ror.org/00x6h5n95 theo scheme ROR. Bản ghi Zenodo chỉ có tên Zenodo. Trường publisher dạng đối tượng chỉ có khi gọi với publisher=true.

Types

Cả bốn bản ghi có resourceTypeGeneral là Dataset. Trường resourceType tự do thì Dryad ghi dataset, ba bản ghi Zenodo để trống. Dùng resourceTypeGeneral để phân loại, vì nó có danh sách giá trị cố định trong schema.

Version

Bản ghi Dryad có version là 4. Bản ghi 10.5281/zenodo.23977456 có version 0.3.0. Hai bản ghi Zenodo của cặp phiên bản đều để trống version. Không thể dựa vào trường version để biết bản nào mới hơn. Quan hệ phiên bản và ngày đăng ký mới cho câu trả lời.

relatedIdentifiers của từng bản ghi

Bản ghi 23977407 có ba quan hệ: IsSupplementTo một DOI bài báo, IsVersionOf DOI 20742567, IsPartOf một ISSN. Bản ghi 20742567 có hai HasVersion. Bản ghi Dryad có một IsCitedBy tới bài báo. Bản ghi 23977456 có hơn mười IsDerivedFrom tới dataset và bài báo, cộng URL GitHub.

Creator là tổ chức

Trường nameType phân biệt Personal và Organizational. Bốn bản ghi trong lab chỉ có creator cá nhân. Với creator là tổ chức, không có ORCID để ghép, và tên tổ chức nằm ngay ở trường name. Mã đọc creator phải kiểm nameType trước khi tách họ và tên.

Thứ tự creator

Thứ tự creator trong bản ghi là thứ tự tác giả khi trích dẫn. Lab giữ nguyên thứ tự và chỉ lưu năm creator đầu cho bảng tóm tắt, còn tổng số creator lưu riêng. Không sắp xếp lại theo tên, vì sẽ làm mất thông tin tác giả chính.

Kiểu định danh lẫn lộn

Trong cùng danh sách quan hệ có DOI, URL và ISSN. Bảng cạnh phải giữ cột kiểu định danh. Một URL GitHub không gọi được doi.org, một ISSN không phải DOI của tạp chí. Mã chỉ xử lý DOI phải lọc theo kiểu, không theo chuỗi có dấu gạch chéo.

Trường đếm

Bản ghi có citationCount và viewCount. Bản ghi 23977407 có citationCount 1, viewCount 0. Các con số này do DataCite tổng hợp từ dữ liệu sự kiện, không phải từ kho. Lab ghi lại nhưng không dùng làm thước đo chất lượng.

Chuẩn hóa relationType cùng DOI liên quan trong DataCite API DOI metadata

Phần này biến danh sách quan hệ thành bảng cạnh có thể đối soát.

Một cạnh một dòng

Mỗi relatedIdentifier thành một dòng: DOI nguồn, relationType, kiểu định danh, đích đã chuẩn hóa. Đích kiểu DOI được chuẩn hóa như đầu vào. Đích URL và ISSN giữ nguyên. Lab sinh 24 cạnh từ bốn bản ghi.

Bảng quan hệ ngược

DataCite định nghĩa các cặp quan hệ ngược nhau. Lab dùng bảng nhỏ: IsVersionOf với HasVersion, IsSupplementTo với IsSupplementedBy, IsCitedBy với Cites, IsDerivedFrom với IsSourceOf, IsPartOf với HasPart. Với mỗi cạnh DOI, lab biết bên kia nên ghi quan hệ nào nếu có ghi.

INV = {"IsVersionOf": "HasVersion", "HasVersion": "IsVersionOf",
       "IsSupplementTo": "IsSupplementedBy", "IsCitedBy": "Cites",
       "IsDerivedFrom": "IsSourceOf", "IsPartOf": "HasPart"}

Hỏi cơ quan của đích

Với tám cạnh DOI đầu tiên, lab hỏi doi.org/ra để biết đích thuộc DataCite hay Crossref. Bài báo đích của IsSupplementTo và IsCitedBy đều thuộc Crossref. Dataset và phần mềm đích đều thuộc DataCite. Chỉ đích DataCite mới kiểm được quan hệ ngược bằng cùng API.

Quan hệ phiên bản hai chiều

Cạnh 23977407 IsVersionOf 20742567 có chiều ngược: bản ghi 20742567 có HasVersion 23977407. Cạnh 20742567 HasVersion 20742568 cũng có chiều ngược IsVersionOf. Zenodo ghi đủ cả hai chiều cho quan hệ phiên bản. Đây là quan hệ đáng tin nhất trong lab.

Concept DOI và version DOI

Trên Zenodo, 20742567 đóng vai DOI đại diện cho mọi phiên bản, còn 20742568 và 23977407 là hai phiên bản cụ thể. Ngày đăng ký cho thấy 20742567 đăng ký 18/06/2026, còn 23977407 đăng ký 05/11/2026. Trích dẫn tới DOI đại diện luôn trỏ tới phiên bản mới nhất, trích dẫn tới DOI phiên bản cố định một bản.

Quan hệ bổ trợ một chiều

Cạnh 23977456 IsSupplementTo 23264879, một phần mềm trên DataCite, không có chiều ngược IsSupplementedBy trong bản ghi đích. Cạnh IsDerivedFrom tới dataset 14199536 cũng không có IsSourceOf ở bên kia. Lời khai chỉ nằm ở một phía.

Bảng cạnh đã đối soát

Bảng cạnh đối soát

Bảng: Bảng cạnh đã đối soát

Nguồn	Quan hệ	Đích	Cơ quan đích	Chiều ngược
zenodo.23977407	IsVersionOf	zenodo.20742567	DataCite	có HasVersion
zenodo.20742567	HasVersion	zenodo.20742568	DataCite	có IsVersionOf
zenodo.20742567	HasVersion	zenodo.23977407	DataCite	có IsVersionOf
zenodo.23977407	IsSupplementTo	10.1080/15487733.2025.2506199	Crossref	không kiểm
dryad.j6q573nxg	IsCitedBy	10.1021/acs.macromol.6c02209	Crossref	không kiểm
zenodo.23977456	IsSupplementTo	zenodo.23264879	DataCite	không có
zenodo.23977456	IsDerivedFrom	zenodo.14199536	DataCite	không có

Đích là URL và ISSN

Bốn cạnh trong lab có đích không phải DOI: một URL GitHub, một URL DepMap và hai cạnh ISSN trỏ tới cùng một tạp chí. Các cạnh này không đối soát được bằng API DataCite. Bảng đầu ra giữ chúng nhưng đánh dấu là không kiểm, để người đọc không hiểu nhầm là đã xác nhận.

Giới hạn số cạnh kiểm

Lab chỉ kiểm cơ quan và chiều ngược cho tám cạnh DOI đầu tiên để giữ số lượt gọi thấp. Bản ghi 23977456 có hơn mười cạnh tới bài báo Crossref chưa được hỏi cơ quan. Với danh sách lớn, nên gom DOI đích lại, bỏ trùng rồi mới hỏi.

Không tự thêm cạnh ngược

Bảng đầu ra không tự sinh cạnh ngược cho những quan hệ chỉ một phía ghi. Nếu cần đồ thị vô hướng để phân tích, đánh dấu cạnh suy ra bằng cột riêng. Người đọc bảng phải biết cạnh nào là lời khai trong dữ liệu, cạnh nào do pipeline thêm.

Đối soát bản ghi thiếu trường và provenance của từng DOI trong DataCite API DOI metadata

Phần này ghi lại bản ghi đến từ đâu, thay đổi khi nào và thiếu gì.

Kho và tổ chức

Ba bản ghi Zenodo có client cern.zenodo và provider cern. Bản ghi Dryad có client dryad.dryad và provider dryad. Client là kho đã đăng ký DOI. Đây là trường provenance quan trọng nhất: ai chịu trách nhiệm cho metadata.

Trạng thái và schema

Bốn bản ghi đều có state là findable, schemaVersion là kernel-4. Bản ghi ở trạng thái draft hoặc registered không hiện qua API công khai, theo tài liệu chỉ API thành viên mới xem được. Pipeline chỉ thấy DOI findable.

Endpoint activities

Provenance của record

Lab gọi /dois/{doi}/activities cho từng bản ghi. Bản ghi 23977407 có 1 hoạt động create lúc 2026-11-05T11:42:49Z. Bản ghi 20742567 có 3 hoạt động: create ngày 18/06/2026, update ngày 07/09/2026 và update ngày 05/11/2026. Bản ghi Dryad có create rồi update cách nhau một giây.

Cập nhật lan sang bản ghi khác

Bản ghi 20742567 được cập nhật lúc 11:42:49 ngày 05/11/2026, đúng giây bản ghi 23977407 được tạo. Khi Zenodo tạo phiên bản mới, nó cập nhật cả DOI đại diện để thêm HasVersion. Ngày updated của DOI đại diện vì vậy không phải ngày dữ liệu thay đổi.

Danh sách trường thiếu

Ba bản ghi Zenodo thiếu resourceType. Hai bản ghi Zenodo thiếu version. Bản ghi Dryad có 5 trên 7 creator thiếu ORCID. Các creator trong lab đều có ít nhất một affiliation, nhưng phần lớn affiliation không có ROR. Bảng đầu ra ghi danh sách này cho từng DOI.

Ghi provenance của chính pipeline

Ngoài provenance của bản ghi, pipeline ghi provenance của lần lấy: URL đã gọi, mã trạng thái, thời gian phản hồi, thời điểm gọi. Lab lưu 27 dòng như vậy. Khi bản ghi thay đổi về sau, có thể biết số liệu trong bảng là của lần gọi nào.

Ngày đăng ký và ngày xuất bản

Bản ghi có registered là lúc DOI được đăng ký với DataCite và publicationYear là năm xuất bản do kho khai. Hai giá trị này trả lời hai câu hỏi khác nhau. Khi thống kê theo năm, ghi rõ dùng trường nào, nhất là với dataset cũ được kho đăng ký DOI muộn.

Bản ghi mới tạo trong ngày

Nhiều bản ghi trong lab được tạo hoặc cập nhật đúng ngày chạy. Truy vấn sắp xếp theo ngày tạo giảm dần nên chọn trúng bản ghi mới. Với bản ghi mới, citationCount và viewCount thường còn rất thấp, không phản ánh giá trị dataset.

Bảng dataset đầu ra

Bảng: Bảng dataset đầu ra

DOI	Kho	Creator (có ORCID)	version	Hoạt động	Thiếu
zenodo.23977407	cern.zenodo	5 (5)	trống	1	version, resourceType
zenodo.20742567	cern.zenodo	5 (5)	trống	3	version, resourceType
dryad.j6q573nxg	dryad.dryad	7 (2)	4	2	ORCID 5 creator
zenodo.23977456	cern.zenodo	1 (1)	0.3.0	1	resourceType

Đầu ra nghiệm thu DataCite API DOI metadata: dataset DOI creator relatedIdentifier và provenance từng record

Phần này gom đầu ra thành bản ghi có thể lưu.

Tệp đầu ra

Lab sinh result.json gồm phiên bản Python và requests, bốn bản ghi đã chuẩn hóa, hai DOI lỗi có lý do, 24 cạnh quan hệ, kết quả đối soát chiều ngược và nhật ký 27 lượt gọi. out.txt là bản in của cùng dữ liệu.

Danh sách kiểm tra

Danh sách nghiệm thu

• DOI đầu vào được chuẩn hóa về chữ thường, bỏ tiền tố URL và doi:.
• Cơ quan đăng ký được hỏi trước khi gọi DataCite.
• DOI Crossref và DOI không tồn tại được tách thành hai loại lỗi.
• ORCID được chuẩn hóa về một định dạng.
• Mỗi relatedIdentifier là một cạnh có kiểu định danh.
• Cạnh DOI tới DataCite được kiểm chiều ngược.
• Mỗi bản ghi có client, provider, state, ngày tạo, ngày cập nhật và activities.

Những gì lab chưa chạy

Chưa thử truy vấn lớn có phân trang cursor. Chưa thử định dạng khác như DataCite XML hay schema.org qua content negotiation. Chưa thử API GraphQL của DataCite. Chưa kiểm chiều ngược cho mọi cạnh, chỉ tám cạnh đầu. Chưa dùng API thành viên.

Câu kết luận được phép viết

Câu được phép viết là: với bốn DOI trong lab, quan hệ phiên bản của Zenodo được ghi hai chiều, còn quan hệ bổ trợ và nguồn gốc tới DOI DataCite khác chỉ ghi một chiều. Câu không được phép viết là: DataCite không ghi quan hệ ngược. Lab chỉ kiểm vài cạnh của hai kho.

Vận hành pipeline với DataCite API DOI metadata

Phần này chuyển kết quả lab thành quy tắc cho pipeline chạy thật.

Nhịp gọi và User-Agent

Lab nghỉ 1 giây giữa các lượt gọi và không gặp lỗi giới hạn nào. Pipeline thật nên giữ nhịp tương tự, gửi User-Agent có tên và email liên hệ của nhóm, và lưu response để không gọi lại cùng DOI trong cùng ngày.

Bộ nhớ đệm theo ngày updated

Lưu bản ghi kèm trường updated. Lần sau, chỉ tải lại khi cần dữ liệu mới hơn. Với danh sách lớn, dùng truy vấn tìm kiếm theo khoảng ngày cập nhật thay vì gọi từng DOI. Lab chưa thử cách này nên chỉ nêu như hướng làm.

Tách hai API

Giữ bảng cơ quan đăng ký cho từng DOI. DOI Crossref gửi tới Crossref, DOI DataCite gửi tới DataCite. Một pipeline gửi mọi DOI tới cả hai API sẽ gấp đôi số lượt gọi và nhận 404 cho một nửa.

Ghép với dữ liệu tổ chức

Affiliation trong lab có ROR ở một số creator và không có ở số khác, với nhiều cách ghi tên cho cùng tổ chức. Nếu cần thống kê theo tổ chức, đưa tên affiliation thô qua bước ghép ROR riêng, giữ chuỗi gốc và ghi mức tin cậy. Không ghép bằng so sánh chuỗi đơn giản.

Không coi lời khai là sự thật

relatedIdentifiers là lời khai của người nộp dữ liệu. Một dataset khai IsDerivedFrom mười bài báo không có nghĩa đã được kiểm. Báo cáo dùng dữ liệu này nên ghi rõ đây là quan hệ do kho ghi nhận.

Giấy phép metadata

Metadata DataCite thường được phát hành theo giấy phép mở, nhưng dataset bên dưới có giấy phép riêng trong trường rightsList. Pipeline chỉ lưu metadata không có nghĩa được tải và phân phối lại tệp dữ liệu. Kiểm rightsList trước khi tải dataset.

Lưu cả response gốc

Ngoài bảng đã chuẩn hóa, lưu nguyên response JSON của từng DOI vào một thư mục theo ngày. Khi bảng chuẩn hóa có lỗi, có thể chạy lại bước chuẩn hóa trên response gốc mà không gọi API thêm lần nào. Response gốc cũng là bằng chứng nếu kho sửa metadata về sau.

Đếm lỗi theo loại

Nhật ký gọi API nên được gom theo mã trạng thái và theo cơ quan đăng ký. Tỷ lệ 404 cao ở một nhóm DOI thường là dấu hiệu nhóm đó thuộc Crossref hoặc bị gõ sai từ nguồn trích dẫn. Lab có hai lượt 404 trên sáu DOI đầu vào, đều đã có lý do rõ.

Kiểm giá trị lạ của schema

Thêm một bước kiểm resourceTypeGeneral và relationType nằm trong danh sách của schema. Giá trị lạ có thể do kho nhập sai hoặc do schema đổi phiên bản. Ghi lại thay vì bỏ qua, để biết khi nào cần cập nhật bảng quan hệ ngược của pipeline.

Báo lỗi metadata cho kho

Khi thấy bản ghi thiếu ORCID hay ROR mà thông tin đó có thật, báo cho kho đã đăng ký DOI, tức client trong bản ghi. Pipeline không sửa được metadata của người khác. Kho mới là bên có quyền và có trách nhiệm cập nhật.

Proxy ở đâu trong luồng

API công khai của DataCite không cần IP riêng. Proxy chỉ có vai trò khi hạ tầng của nhóm cần đi ra Internet qua một điểm cố định, hoặc khi tải tệp dataset lớn từ nhiều kho. Khi cần IP tại Việt Nam, anh em có thể mua proxy tại trang chủ ProxyVN. Vai trò của proxy có ở bài Web Scraping proxy là gì, cách ghi chuỗi cấu hình có ở bài định dạng proxy.

DataCite API DOI metadata: câu hỏi thường gặp

Các câu dưới đây gom những điểm hay bị hỏi.

Có cần khóa API để đọc metadata không?

Không. API công khai đọc được bản ghi findable mà không cần xác thực.

Vì sao DOI hợp lệ lại trả 404?

Có thể DOI thuộc cơ quan khác. Trong lab, DOI Crossref trả 404 ở DataCite. Hỏi doi.org/ra trước.

ORCID trong bản ghi có cùng định dạng không?

Không. Zenodo ghi mã trần, Dryad ghi URL. Chuẩn hóa trước khi so.

Quan hệ có luôn được ghi hai chiều không?

Không. Trong lab, quan hệ phiên bản có hai chiều, quan hệ bổ trợ và nguồn gốc chỉ một chiều.

Biết phiên bản mới nhất bằng cách nào?

Đọc HasVersion của DOI đại diện và so ngày đăng ký. Trường version có thể trống.

Ngày updated có phải ngày dữ liệu đổi không?

Không hẳn. DOI đại diện được cập nhật khi có phiên bản mới, dù nội dung của nó không đổi.

Endpoint activities cho biết gì?

Lịch sử create và update của bản ghi, có thời điểm và số phiên bản metadata.

DataCite API DOI metadata và những điều cần nhớ

DataCite API DOI metadata cho đọc creator, loại tài nguyên, quan hệ và lịch sử của DOI dataset qua API công khai, nhưng quan hệ là lời khai cần đối soát. Lab cho thấy ORCID hai định dạng, quan hệ phiên bản hai chiều còn quan hệ bổ trợ một chiều, và DOI Crossref trả 404. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em hỏi cơ quan đăng ký trước rồi mới đọc DataCite API DOI metadata.