Một tài liệu được số hóa thành ba ảnh rõ nét, nhưng trình xem đưa trang thứ ba lên trước trang thứ hai. Người đọc có thể phóng to từng ảnh mà vẫn hiểu sai diễn biến của tài liệu. IIIF trên website thư viện cần giải quyết cả cấu trúc và ngữ cảnh, không chỉ khả năng mở một ảnh lớn.
Bài viết đi từ bộ tài liệu QA ba trang do đội biên tập tự tạo để phân biệt đối tượng số, các góc nhìn và tài nguyên ảnh. Phần kỹ thuật tham chiếu IIIF Presentation API 3.0 cùng cookbook chính thức. Không có kho lưu trữ khách hàng, phép thử trình xem thật hoặc quyền sử dụng hiện vật nào được suy ra từ ví dụ này.
IIIF trên website thư viện không chỉ là một thư viện ảnh
Presentation API 3.0 của IIIF mô tả thông tin phục vụ trình xem đối tượng số phức hợp: cấu trúc, thứ tự các phần và ngữ cảnh cho người đọc. Manifest thường đại diện một đối tượng; các Canvas được đưa vào để trình bày những góc nhìn của đối tượng đó. Tài nguyên hình ảnh không tự thay thế toàn bộ cấu trúc này.
Với một bức tranh chỉ có một mặt cần xem, quan hệ có thể đơn giản. Với một cuốn sổ, một tờ gấp hoặc hai mặt bưu thiếp, người phụ trách phải quyết định những phần nào thuộc cùng một đối tượng và người đọc đi qua chúng theo cách nào. Đây là công việc mô tả nội dung trước khi chọn hiệu ứng lật trang hoặc màu thanh công cụ.
Giả sử bộ QA có trang bìa, trang nội dung A và trang nội dung B. Nếu chỉ nhập ba ảnh vào một gallery rồi sắp theo thời gian upload, thứ tự có thể phụ thuộc việc nhân viên tải file nào trước. Thứ tự hiển thị nên phản ánh quyết định biên mục đã xác nhận, không phải một đặc điểm ngẫu nhiên của lần nhập dữ liệu.
Người dùng cũng cần biết mình đang xem phần nào. Nhãn “ảnh số 2” có thể là số thứ tự trong trình xem, nhưng chưa chắc là số trang in trên tài liệu. Một bản có bìa, tờ trắng hoặc trang không đánh số dễ làm hai con số khác nhau. Đội biên tập nên giữ ý nghĩa của nhãn nhất quán và không tự thêm số trang nguồn chưa có.
Làm thử với ba trang trước khi đưa cả kho lên
Cookbook Simple Manifest — Book dùng trường hợp sách số hóa gồm nhiều ảnh và mô hình hóa thành Manifest. Hướng tiếp cận cũng áp dụng cho đối tượng có nhiều trang, mặt hoặc góc nhìn. Đó là mẫu tham khảo cấu trúc, không phải bằng chứng một hệ thống cụ thể đã nhập hoặc hiển thị đúng tài liệu của đơn vị.
Với bộ QA, hãy viết danh sách mong đợi trước: bìa đứng đầu, tiếp theo A rồi B. Mỗi phần có một định danh ổn định và một nhãn được duyệt. Một người không tham gia viết dữ liệu cần đối chiếu được danh sách đó với nội dung thực sự nhìn thấy, thay vì tin vào việc các tên file đã có số ở đầu.
| Phần giả lập | Người đọc cần hiểu | Điều cần đối chiếu |
|---|---|---|
| Bìa QA | Đây là đầu tài liệu | Đứng trước nội dung A |
| Nội dung A | Đây là phần tiếp sau bìa | Đúng ảnh gắn với phần A |
| Nội dung B | Đây là phần tiếp sau A | Không bị lặp ảnh A hoặc đảo vị trí |
Bảng này là đặc tả dữ liệu thử, không phải dữ liệu biên mục tiêu chuẩn áp dụng cho mọi tài liệu. Tài liệu khác có thể cần trình tự khác hoặc nhiều cách điều hướng. Điều có thể tái sử dụng là cách xác định kết quả mong đợi đủ cụ thể trước khi nhập hàng loạt.
Canvas cần đúng tài nguyên, không chỉ đúng nhãn
Trong ví dụ, một nhãn “Nội dung B” có thể vẫn gắn nhầm ảnh A. Chỉ đọc danh sách nhãn sẽ không phát hiện sai sót. Phép kiểm phải đi tới nội dung được trình bày và đối chiếu một dấu hiệu khác biệt có chủ đích trên từng trang QA. Đây là lý do bộ thử cần ba trang khác nhau, thay vì ba ảnh gần giống chỉ đổi tên.
Tương tự, ảnh có thể được phục vụ qua một dịch vụ hoặc đường dẫn khác với nơi lưu mô tả đối tượng. Đội triển khai cần lập rõ quan hệ đó trong phương án của mình, rồi kiểm đường truy cập thực tế. Không nên cho rằng một mô tả JSON đọc được đã chứng minh mọi tài nguyên liên quan đều tải được hoặc đều có quyền công khai.
Thứ tự và mục lục là hai quyết định có liên quan
Một tài liệu dài có thể cần các nhóm nội dung để người đọc chuyển nhanh. Thứ tự tuyến tính của từng trang vẫn quan trọng, nhưng không nhất thiết là cách duy nhất để điều hướng. Presentation API có các cấu trúc phục vụ mô tả đó; việc chọn nhóm nào và gọi tên ra sao phải dựa vào tài liệu và mục đích của bộ sưu tập.
Đừng tạo một mục lục dựa vào suy đoán từ vài từ OCR rồi công bố như cấu trúc gốc. Nếu đó là mục lục do đơn vị bổ sung, cần thể hiện đúng tính chất và có người duyệt. Một tiện ích tìm nhanh có giá trị khi nó giúp người đọc, không khi nó khiến người đọc nhầm một diễn giải mới với thông tin vốn có của hiện vật.
Giữ riêng ba ranh giới ngoài trình xem
Giới hạn đầu tiên là quyền sử dụng nội dung. Một ảnh tải thành công không tự nói ai được phép xem hoặc tái sử dụng. Đơn vị cần quyết định quyền với tài liệu và ảnh số, rồi chọn cách công bố phù hợp. Không đưa bản có hạn chế vào kho ảnh công khai chỉ vì trang trình xem nằm sau đăng nhập.
Nếu đang xây cơ chế cấp quyền, hãy khảo sát quyền truy cập ở nơi phục vụ file như một phần riêng. Không gọi một đường dẫn dài hoặc khó đoán là biện pháp bảo vệ đủ. Các quyết định về phiên đăng nhập, thu hồi quyền và kiểm thử truy cập phải thuộc thiết kế được duyệt, không được suy ra từ chữ IIIF.
Giới hạn thứ hai là khả năng tìm trong nội dung. Đặc tả Presentation API phân biệt phạm vi này với Content Search API. Do đó, có Manifest và một trình xem chưa chứng minh người dùng tìm được từ trong mọi trang. Nếu đơn vị cần tìm kiếm OCR hoặc bản chép, phải nêu nguồn dữ liệu, chất lượng và hành vi tìm trong yêu cầu riêng.
Ví dụ, một trang QA có từ “mùa” nhưng bản chép sai thành từ khác. Kết quả không tìm thấy chưa chắc do trình xem mất trang. Đội hỗ trợ cần biết phần nào phục vụ trình bày, phần nào cung cấp bản chép và phần nào thực hiện tìm kiếm. Tách câu hỏi giúp giải quyết đúng lỗi thay vì tải lại toàn bộ ảnh khi chưa có căn cứ.
Giới hạn thứ ba là khả năng được tìm thấy từ bên ngoài. Đặc tả không đặt mục tiêu trực tiếp cung cấp metadata để máy tìm kiếm index đối tượng. Website vẫn cần trang mô tả và cấu trúc khám phá phù hợp với thiết kế của đơn vị. Không dùng việc một Manifest hợp lệ để hứa Google đã đọc, index hoặc đem lại truy cập cho bộ sưu tập.
Ba ranh giới này có thể cùng xuất hiện trên một màn hình, nhưng cần bằng chứng khác nhau. Nhóm triển khai nên ghi riêng kết quả xem, quyền truy cập và tìm kiếm. Một bảng nghiệm thu có ba trạng thái rõ thường dễ đối chiếu hơn một chữ “hoàn tất tích hợp” không nói đã thử việc gì.
Nghiệm thu bằng lỗi dữ liệu có chủ đích
Bộ QA ba trang cho phép tạo vài lỗi nhỏ mà không đụng tài liệu thật. Đầu tiên, đảo A và B rồi xem phép đối chiếu có phát hiện được không. Tiếp theo, giữ đúng thứ tự nhưng gắn cùng ảnh A cho cả hai phần. Nếu người kiểm chỉ đếm đủ ba trang, lỗi thứ hai vẫn lọt qua.
Thử tiếp một nhãn dài hoặc nhãn có dấu tiếng Việt để kiểm cách hiển thị trên mobile. Người đọc cần nhận diện được trang và có đường chuyển tiếp rõ, không bị buộc đoán từ một tên file cắt giữa chừng. Phép thử này không thay toàn bộ kiểm tra khả năng tiếp cận, nhưng giúp phát hiện một vướng mắc thực tế trong hành trình.
Với một tài nguyên cố ý không có trong môi trường QA, quan sát thông báo lỗi và đường quay lại. Không nên để một ảnh không tải được biến thành một trang trắng hoàn toàn giống tờ trắng của tài liệu. Cách thể hiện lỗi phụ thuộc trình xem, vì thế cần thử đúng sản phẩm và cấu hình đã chọn trước khi đưa ra cam kết.
Sau đó, đối chiếu tổng thể với danh sách đã duyệt: đúng đối tượng, đúng số phần, đúng thứ tự, đúng nhãn và đúng tài nguyên. Lưu kết quả gắn với phiên bản dữ liệu thử cùng trình xem thực sự đã dùng. Bài viết chỉ đề xuất kế hoạch; chưa có kết quả chạy nào được thay bằng ảnh minh họa ở đây.
Khi mở rộng nhập liệu, nên có người chịu trách nhiệm cho mô tả đối tượng và người kiểm ánh xạ tài nguyên. Không cần để từng người quản trị tự xây một cấu trúc khác nhau cho tài liệu cùng loại. Tuy nhiên, một mẫu chung cũng không được ép tài liệu có tờ gấp, nhiều mặt hoặc thứ tự đặc biệt thành ba trang tiêu chuẩn chỉ vì ví dụ QA dùng ba trang.
Nếu cần khảo sát website thư viện, kho lưu trữ hoặc trình xem đối tượng số, hãy chuẩn bị một tài liệu tự tạo được phép chia sẻ và hành trình người đọc mong muốn. Giá: Liên hệ. Nhận tư vấn & báo giá theo cấu trúc nội dung, quyền và phép kiểm cần có; không cần gửi hiện vật số có hạn chế trong bước tư vấn ban đầu.
