- Trong quá trình cố gắng tạo một ứng dụng ghi chép sách gọn gàng và thực dụng như ứng dụng ghi chép phim Letterboxd, vấn đề mang tính cấu trúc của hệ thống ISBN đã trở thành trở ngại cốt lõi
- Khi dùng Google Books API cho tính năng tìm kiếm sách, đã phát hiện vấn đề là nhiều phiên bản ISBN của cùng một tác phẩm bị trả về thành các mục riêng biệt
- Điều này xảy ra vì trong cấu trúc thư mục học (mô hình FRBR), ‘tác phẩm (work)’, ‘biểu đạt (expression)’ và ‘hiện thân (manifestation)’ được phân biệt; vì vậy ngay cả khi người dùng chỉ muốn ghi lại việc ‘đã đọc một cuốn sách’, dữ liệu vẫn bị chia nhỏ quá mức
- Dù OpenLibrary cung cấp cấu trúc dữ liệu lấy ‘tác phẩm’ làm trung tâm, nó vẫn tồn tại trùng lặp và thiếu hoàn chỉnh, nên chưa thể là một giải pháp thay thế hoàn chỉnh
- Trong lĩnh vực sách không có hạ tầng metadata công khai chất lượng cao như cơ sở dữ liệu phim TMDB, và đây là yếu tố cản trở chính trong việc phát triển một nền tảng xã hội xoay quanh sách
So sánh giữa Letterboxd và nền tảng sách
- Letterboxd cho phép quản lý việc ghi chép trải nghiệm xem phim một cách dễ dàng nhờ giao diện gọn gàng và các tính năng xã hội không xâm lấn
- Người dùng có thể đơn giản ghi lại bộ phim đã xem và thời điểm xem
- Ngược lại, GoodReads khiến việc ghi chép sách trở nên bất tiện vì UI phức tạp và cấu trúc nhiều tầng nhấp chuột
- ‘Sách đã đọc’ và ‘sách sẽ đọc’ bị trộn lẫn trên cùng một màn hình, còn thử thách đọc sách, bản tin và các yếu tố phụ trợ khác chiếm dụng không gian
- Lý do GoodReads bất tiện như vậy là vì nó là sản phẩm phái sinh có mức độ ưu tiên thấp của mảng kinh doanh bán sách của Amazon
- Storygraph cũng có vấn đề tương tự, nên cuối cùng người dùng phải quản lý ghi chép cá nhân bằng tệp Obsidian
Google Books API và vấn đề ISBN
- Để xây dựng tính năng tìm kiếm sách, tác giả đã dùng Google Books API, nhưng gặp hiện tượng cùng một tác phẩm xuất hiện trùng lặp dưới nhiều ISBN
- Ví dụ, khi tìm “The Last Unicorn”, các bản bìa cứng, bìa mềm, eBook, bản sửa đổi... được trả về với các ISBN khác nhau
- Mỗi ISBN đại diện cho một định dạng hoặc một ấn bản khác nhau, nhưng người dùng chỉ đơn giản muốn ghi lại việc ‘đã đọc cuốn sách đó’
- Cấu trúc này làm cho việc tìm kiếm và tích hợp dữ liệu trở nên khó khăn, khiến nó không phù hợp để xây dựng một hệ thống ghi chép theo đơn vị tác phẩm duy nhất
Mô hình FRBR và cách tiếp cận theo đơn vị ‘tác phẩm’
- Mô hình FRBR được dùng trong ngành thư viện phân chia dữ liệu sách thành bốn tầng
- Work (tác phẩm): bản thân sáng tạo trừu tượng (ví dụ: tiểu thuyết "The Last Unicorn")
- Expression (biểu đạt): một phiên bản cụ thể
- Manifestation (hiện thân): định dạng vật lý của một phiên bản cụ thể (bìa mềm, bìa cứng...)
- Item (cá thể): vật thể vật lý riêng lẻ trong một bộ sưu tập
- Google Books chủ yếu trả về dữ liệu ở cấp độ ‘biểu đạt’ hoặc ‘hiện thân’, trong khi người dùng lại cần đơn vị trừu tượng ở cấp ‘tác phẩm’
- OpenLibrary cung cấp cấu trúc dữ liệu lấy ‘tác phẩm’ làm trung tâm, nhưng vẫn còn các mục trùng lặp
- Ví dụ: khi tìm Hotel Iris của Yoko Ogawa, cùng một tác phẩm bị hiển thị lặp lại bốn lần
Giới hạn của chất lượng dữ liệu và hệ sinh thái
- Letterboxd hoạt động dựa trên The Movie Database (TMDB), và TMDB sở hữu khoảng 1 triệu dữ liệu phim
- Trong khi đó, OpenLibrary chứa hơn 40 triệu tác phẩm, nhưng có rất nhiều dữ liệu chưa hoàn chỉnh và chưa được làm sạch
- Dữ liệu phim có chất lượng cao nhờ sự kết hợp giữa nền tảng thương mại và đóng góp từ cộng đồng, còn dữ liệu sách thì quy mô lớn và thiếu nguồn tài trợ
- Vì vậy, hiện không có dữ liệu nền tảng cần thiết để tạo ra một dịch vụ kiểu Letterboxd dành cho sách
Kết luận và những thử nghiệm sắp tới
- Do chưa tồn tại một hạ tầng metadata sách mã nguồn mở hoàn chỉnh, việc phát triển nền tảng ghi chép sách là bài toán khó hơn rất nhiều so với phim
- Tác giả vẫn dự định tiếp tục thử xây dựng một hệ thống ghi chép sách độc lập
- Cũng như trải nghiệm tìm ra gu phim, việc ghi chép sách cũng cần một cách tiếp cận mang tính cá nhân hóa
3 bình luận
Thì đúng là... ISBN là mã định danh của ấn phẩm xuất bản chứ không phải mã định danh của nội dung...
Tiêu đề câu view quá đà luôn haha
Cũng đúng là hệ thống ISBN thực ra không cân nhắc nhiều đến việc phân loại một cách có hệ thống...
Theo quy tắc thì mỗi lần tái bản đều phải được cấp một số riêng, nhưng vì danh mục thấp nhất lại là nhà xuất bản nên, dù có nhu cầu phân loại theo từng tác phẩm, việc quản lý cũng không hề dễ.
Ý kiến trên Hacker News
Cấu trúc cơ sở dữ liệu của MusicBrainz làm tôi liên tưởng đến chuyện này
Ví dụ, album Nevermind của Nirvana là một release group duy nhất, nhưng có nhiều phiên bản phát hành theo băng cassette, CD, LP, bản quảng bá và tái bản theo từng quốc gia
Có trường hợp được phân biệt bằng số catalog hoặc mã vạch khác nhau, nhưng cũng có trường hợp dù ghi cùng một mã thì thực tế vẫn là các phiên bản khác nhau
Ngay cả cùng một bản thu âm, nó vẫn có thể khác nhau do remaster, biên tập hoặc kiểm duyệt
MusicBrainz theo dõi rất chi tiết những khác biệt này và phân biệt rõ đâu là cùng một bản ghi âm, đâu thì không
Với các trường hợp như bản cover hay tác phẩm tiêu chuẩn được nhiều nghệ sĩ thu âm, họ liên kết thông tin nhà soạn nhạc và người viết lời ở cấp ‘work’
Tôi thấy kiểu thiết kế cơ sở dữ liệu quan hệ tinh vi này rất hữu ích để ghi nhận sự giống nhau và khác nhau của các tác phẩm sáng tạo
Liên kết liên quan
bookbrainz.org/about
Nếu dùng schema tương tự MusicBrainz thì tôi kỳ vọng việc trích xuất dữ liệu sẽ rất dễ dàng
Tôi đã tạo tài khoản, tự tải dữ liệu lên và sau nhiều lần chỉnh sửa thì cuối cùng cũng đăng ký thành công
Tôi còn tìm được thông tin về chiếc CD bản Úc tương tự trên một trang web Trung Quốc để tham khảo, rồi nhận ra là có những phiên bản khác nhau rất nhỏ theo từng thị trường
Vì mọi người quá lỏng lẻo trong việc cập nhật ‘định danh duy nhất’, tôi rất đồng cảm với đội ngũ MusicBrainz
Bản năm 1987 và bản năm 1989 (bản bỏ bài ‘Peace Train’) có cùng số UPC
Tôi còn nhớ hồi giữa thập niên 90 đã vất vả tìm bản trước khi bị cắt ở các cửa hàng CD cũ
Phần còn lại gây rối vì tồn tại nhiều phiên bản khác nhau theo từng khu vực với số lượng bài hát khác nhau
Nếu có tính năng ghi rõ thông tin nghệ sĩ cho từng track thì có lẽ độ chính xác tìm kiếm sẽ cao hơn
Ngay cả khi chỉ khác ở mức sửa lỗi chính tả cũng rất khó phân biệt
Wikidata là một cơ sở dữ liệu mở tương thích FRBR, và trong vài năm gần đây chất lượng dữ liệu sách đã được cải thiện đáng kể
Hotel Iris của Yoko Ogawa được nêu làm ví dụ thực ra không phải cùng một tác phẩm mà là các bản dịch khác nhau
Bản dịch nên được xem là tác phẩm phái sinh khác với nguyên tác
Tuy vậy danh mục hiện đang bị trộn lẫn nên có nhiều lỗi
OpenLibrary gộp chúng thành một work và lưu ngôn ngữ cùng thông tin dịch giả ở edition
Sự trùng lặp hiện tại có vẻ là vấn đề phát sinh trong quá trình tự động hợp nhất theo từng ngôn ngữ
Lý tưởng nhất là để người dùng có thể khám phá cả nguyên tác lẫn bản dịch cùng nhau
Tôi đề xuất LibraryThing
Cá nhân tôi thấy nó tốt hơn Goodreads rất nhiều
Điều quan trọng là phải phân biệt cấu trúc WEMI của sách (work, expression, manifestation, item)
“Tôi đã đọc Don Quixote” là câu chuyện ở cấp work, còn “cuốn sách của tôi có vết cà phê” là câu chuyện ở cấp item
Trong một cuộc thi đọc sách cấp bang, sách chỉ được quản lý bằng ISBN nên học sinh rất khó tìm
Vì thế người ta đã thêm một phép join SQL dùng cơ sở dữ liệu ánh xạ ISBN của WorldCat để liên kết các ISBN khác nhau nhưng cùng nội dung
Kết quả là trong 10 năm, học sinh đã đọc thêm hơn một triệu cuốn sách
Anna’s Archive đã đóng góp lớn cho việc sắp xếp dữ liệu liên quan đến ISBN
Họ đã scrape WorldCat để sử dụng, và hiện còn đang xây dựng cả cơ sở dữ liệu ISSN (ấn phẩm định kỳ)
So với sách thì dữ liệu ISSN hiện còn rất thiếu
Có người nhắc lại rằng Open Library bắt đầu từ những công việc đầu tiên của Brewster Kahle (người sáng lập Internet Archive) và Aaron Swartz
Blog liên quan
Đã có nhiều lần tôi xem sách ở hiệu sách rồi mua về, đến lúc về nhà mới phát hiện mình đã có sẵn đúng bản đó
Nếu có thể tìm trong danh sách sở hữu của mình bằng ISBN thì đã tránh được những lần mua trùng như vậy
Tôi từng làm một trang quản lý sách như dự án cá nhân bằng ISBNDB API
Khi tìm theo tiêu đề, kết quả rất rối vì trộn lẫn vô số ấn bản, ngôn ngữ và kiểu đóng sách
Tôi đã thử sắp xếp kết quả bằng độ tương đồng Jaccard nhưng vẫn không hoàn hảo
Hiện đang cân nhắc OpenLibrary như một phương án thay thế
Tôi thấy ứng dụng StoryGraph khá ổn
Giao diện của nó rất phù hợp với người dùng muốn tránh các tính năng AI
Chức năng tìm kiếm cũng tốt
Cá nhân tôi dùng từ khoảng năm 2017, và chọn nó với mục tiêu thoát khỏi thế độc quyền nhóm
ISBN có chứa mã nhận diện nhà xuất bản, nên ngay cả cùng một cuốn sách vẫn có thể có ISBN khác nhau theo từng thị trường
Đây là dịch vụ miễn phí nên có thể mỗi nước sẽ khác nhau
Vì vậy tên nhà xuất bản không nằm trực tiếp trong đó, nhưng về mặt cấu trúc vẫn có thể nhận diện được