- ระหว่างพยายามสร้างแอปบันทึกการอ่านหนังสือที่เรียบง่ายและใช้งานได้จริงแบบ Letterboxd ปัญหาเชิงโครงสร้างของระบบ ISBN กลายเป็นอุปสรรคสำคัญ
- พบว่าฟังก์ชันค้นหาหนังสือผ่าน Google Books API ส่งคืน ISBN หลายเวอร์ชัน ของงานชิ้นเดียวกันเป็นคนละรายการ
- สาเหตุคือใน โครงสร้างบรรณานุกรม (โมเดล FRBR) มีการแยกระหว่าง ‘งาน’ (work), ‘การแสดงออก’ (expression) และ ‘รูปแบบเผยแพร่’ (manifestation) ทำให้แม้ผู้ใช้แค่อยากบันทึกว่า ‘อ่านหนังสือเล่มนี้แล้ว’ ข้อมูลก็ยังถูกแยกย่อยไว้
- แม้ OpenLibrary จะมีโครงสร้างข้อมูลที่ยึด ‘งาน’ เป็นศูนย์กลาง แต่ก็ยังมีปัญหา ข้อมูลซ้ำและไม่สมบูรณ์ จึงยังไม่ใช่ทางเลือกที่สมบูรณ์
- วงการหนังสือยังขาด โครงสร้างพื้นฐานเมทาดาทาแบบเปิด คุณภาพสูงเหมือนฐานข้อมูลภาพยนตร์ TMDB และนี่คืออุปสรรคหลักของการพัฒนาแพลตฟอร์มโซเชียลที่มีหนังสือเป็นศูนย์กลาง
การเปรียบเทียบระหว่าง Letterboxd กับแพลตฟอร์มหนังสือ
- Letterboxd ทำให้การจัดการบันทึกการดูหนังเป็นเรื่องง่ายด้วย อินเทอร์เฟซที่สะอาดตา และ ฟีเจอร์โซเชียลที่ไม่รบกวนการใช้งาน
- ผู้ใช้สามารถบันทึกได้อย่างง่าย ๆ ว่าดูหนังเรื่องอะไรและเมื่อไร
- ในทางกลับกัน GoodReads กลับทำให้การบันทึกหนังสือยุ่งยากเพราะ UI ซับซ้อนและต้องคลิกหลายชั้น
- ‘หนังสือที่อ่านแล้ว’ กับ ‘หนังสือที่จะอ่าน’ ปะปนอยู่ในหน้าจอเดียวกัน และ องค์ประกอบเสริมอย่างชาเลนจ์การอ่านหรือจดหมายข่าว ก็เข้ามาแย่งพื้นที่
- เหตุผลที่ GoodReads ใช้งานไม่สะดวกเช่นนี้ เพราะมันเป็น ผลิตภัณฑ์ต่อยอดที่มีความสำคัญต่ำในธุรกิจขายหนังสือของ Amazon
- Storygraph ก็มีปัญหาคล้ายกัน ทำให้สุดท้ายผู้ใช้ต้องกลับไปจัดการบันทึกส่วนตัวด้วย ไฟล์ Obsidian
Google Books API และปัญหา ISBN
- แม้จะใช้ Google Books API เพื่อสร้างฟังก์ชันค้นหาหนังสือ แต่ก็พบปัญหาที่งานชิ้นเดียวกันถูกค้นเจอซ้ำจากหลาย ISBN
- ตัวอย่างเช่น เมื่อค้นหา “The Last Unicorn” ระบบจะส่งคืน ฉบับปกแข็ง ปกอ่อน eBook ฉบับปรับปรุง ฯลฯ เป็น ISBN คนละชุด
- ISBN แต่ละรายการหมายถึง รูปแบบหรือฉบับพิมพ์ที่ต่างกัน แต่ผู้ใช้จำนวนมากแค่อยากบันทึกง่าย ๆ ว่า ‘อ่านหนังสือเล่มนี้แล้ว’
- โครงสร้างแบบนี้ทำให้ การค้นหาและการรวมข้อมูล ยุ่งยาก และไม่เหมาะกับการสร้างระบบบันทึกที่ยึดหน่วยเป็นงานชิ้นเดียว
โมเดล FRBR และแนวทางแบบ ‘งาน’
- โมเดล FRBR ที่ใช้ในบรรณารักษศาสตร์ แบ่งข้อมูลหนังสือออกเป็น 4 ชั้น
- Work (งาน): ตัวงานสร้างสรรค์เชิงนามธรรม (เช่น นวนิยาย "The Last Unicorn")
- Expression (การแสดงออก): ฉบับหนึ่ง ๆ ของงานนั้น
- Manifestation (รูปแบบเผยแพร่): รูปแบบทางกายภาพของฉบับนั้น (ปกอ่อน ปกแข็ง เป็นต้น)
- Item (รายการ): วัตถุทางกายภาพแต่ละชิ้นในคอลเลกชัน
- Google Books ส่วนใหญ่ส่งคืนข้อมูลในระดับ ‘การแสดงออก’ หรือ ‘รูปแบบเผยแพร่’ ขณะที่ผู้ใช้ต้องการหน่วยเชิงนามธรรมในระดับ ‘งาน’
- OpenLibrary มีโครงสร้างข้อมูลที่ยึด ‘งาน’ เป็นศูนย์กลาง แต่ก็ยังมี รายการซ้ำ อยู่
- ตัวอย่าง: เมื่อค้นหา Hotel Iris ของ Yoko Ogawa งานเดียวกันกลับแสดงซ้ำ 4 ครั้ง
ข้อจำกัดของคุณภาพข้อมูลและระบบนิเวศ
- Letterboxd ทำงานบนฐานของ The Movie Database (TMDB) ซึ่งมีข้อมูลภาพยนตร์ราว 1 ล้านรายการ
- ขณะที่ OpenLibrary มีผลงานมากกว่า 40 ล้านรายการ แต่ข้อมูลจำนวนมากยังไม่สมบูรณ์และไม่ได้รับการคัดกรองอย่างดี
- ข้อมูลภาพยนตร์มีคุณภาพสูงเพราะเกิดจากการผสานกันของแพลตฟอร์มเชิงพาณิชย์และการมีส่วนร่วมของชุมชน แต่ข้อมูลหนังสือนั้น มีขนาดใหญ่และขาดเงินสนับสนุน
- ด้วยเหตุนี้ จึงยังไม่มีข้อมูลฐานรากที่เหมาะสำหรับสร้าง บริการแบบ Letterboxd สำหรับหนังสือ
บทสรุปและความพยายามต่อจากนี้
- เนื่องจากยังไม่มี โครงสร้างพื้นฐานเมทาดาทาหนังสือแบบโอเพนซอร์ส ที่สมบูรณ์ การพัฒนาแพลตฟอร์มบันทึกหนังสือจึงยากกว่าภาพยนตร์มาก
- ผู้เขียนยังคงตั้งใจจะลองสร้าง ระบบบันทึกหนังสือแบบอิสระ ต่อไป
- เช่นเดียวกับประสบการณ์การค้นหารสนิยมด้านภาพยนตร์ การบันทึกการอ่านหนังสือก็ควรต้องมีแนวทางที่เป็นส่วนตัวมากขึ้น
4 ความคิดเห็น
ก็ใช่นะ... ISBN เป็นตัวระบุของสิ่งพิมพ์ ไม่ใช่ตัวระบุของคอนเทนต์...
ชื่อมันล่อคลิกเกินไปนะ 555
ดูเหมือนว่าช่องสำหรับตัวระบุของคอนเทนต์จะว่างอยู่ครับ T_T
ก็จริงอยู่ว่าระบบ ISBN เองก็ไม่ได้คำนึงถึงการจัดหมวดหมู่อย่างเป็นระบบนัก...
ตามกฎแล้วแม้แต่การพิมพ์ซ้ำแต่ละครั้งก็ต้องกำหนดหมายเลขแยกต่างหาก แต่เพราะหมวดหมู่ระดับล่างสุดกลายเป็นสำนักพิมพ์ไปเสียแล้ว จึงทำให้การจัดการไม่ง่ายนัก แม้จะมีความจำเป็นต้องจัดหมวดหมู่แยกตามผลงานก็ตาม
ความคิดเห็นจาก Hacker News
ทำให้นึกถึงโครงสร้างฐานข้อมูลของ MusicBrainz
ตัวอย่างเช่น อัลบั้ม Nevermind ของ Nirvana เป็น release group เดียว แต่มีเวอร์ชันออกซ้ำหลายแบบตามสื่อหรือประเทศ เช่น เทป, CD, LP, โปรโมชัน เป็นต้น
บางกรณีแยกได้จากหมายเลขแคตตาล็อกหรือบาร์โค้ดที่ต่างกัน แต่บางกรณีแม้จะใช้รหัสเดียวกันก็ยังเป็นคนละเวอร์ชันจริง ๆ
แม้จะเป็นการบันทึกเสียงเดียวกัน ก็อาจต่างกันได้จาก การรีมาสเตอร์ การตัดต่อ หรือการเซ็นเซอร์
MusicBrainz ติดตามความต่างเหล่านี้อย่างละเอียด และแยกให้ชัดว่าเป็นการบันทึกเสียงเดียวกันหรือไม่
ในกรณีอย่างเพลงคัฟเวอร์หรือเพลงมาตรฐานที่มีหลายศิลปินบันทึกเสียงไว้ ก็จะเชื่อมข้อมูลนักแต่งเพลงและผู้แต่งเนื้อร้องไว้ในระดับ ‘work’
รู้สึกว่าการออกแบบ ฐานข้อมูลเชิงสัมพันธ์ที่ละเอียดประณีต แบบนี้มีประโยชน์มากในการบันทึกทั้งความเป็นงานชิ้นเดียวกันและความแตกต่างของงานสร้างสรรค์
ลิงก์ที่เกี่ยวข้อง
bookbrainz.org/about
ถ้าใช้สคีมาคล้ายกับ MusicBrainz ก็น่าจะดึงข้อมูลออกมาใช้งานได้ง่ายมาก
สุดท้ายก็สร้างบัญชี อัปโหลดข้อมูลเอง และแก้ไขอยู่หลายรอบจนลงทะเบียนสำเร็จ
ตอนนั้นไปเจอข้อมูลของ CD ฉบับออสเตรเลียแผ่นเดียวกันจากเว็บไซต์จีนเลยเอามาอ้างอิง และทำให้ตระหนักว่ามีเวอร์ชันที่ต่างกันเล็กน้อยตามแต่ละตลาดจริง ๆ
เลยรู้สึกเห็นใจทีม MusicBrainz มาก ว่าผู้คนมักหละหลวมเกินไปกับการอัปเดต ‘ตัวระบุที่ไม่ซ้ำกัน’
ฉบับปี 1987 กับฉบับปี 1989 (เวอร์ชันที่ตัด ‘Peace Train’ ออก) ใช้หมายเลข UPC เดียวกัน
จำได้ว่าช่วงกลางยุค 90 ต้องพยายามมากกว่าจะหาเวอร์ชันก่อนตัดเพลงออกได้จากร้านขาย CD มือสอง
ที่เหลือทำให้งงเพราะมีหลายเวอร์ชันที่จำนวนแทร็กต่างกันตามภูมิภาค
ถ้ามีฟีเจอร์ที่ระบุข้อมูลศิลปินรายแทร็กได้ ก็น่าจะช่วยให้ค้นหาแม่นขึ้น
ต่อให้ต่างกันแค่แก้คำผิด ก็ยังแยกได้ยาก
Wikidata เป็นฐานข้อมูลเปิดที่เข้ากันได้กับ FRBR และคุณภาพด้านหนังสือดีขึ้นมากในช่วงไม่กี่ปีที่ผ่านมา
ตัวอย่าง Hotel Iris ของ Yoko Ogawa ที่ยกมานั้นไม่ใช่งานชิ้นเดียวกัน แต่เป็น ฉบับแปลคนละฉบับ
งานแปลควรถูกมองว่าเป็นงานดัดแปลงที่แยกจากต้นฉบับ
เพียงแต่รายการปะปนกันอยู่จึงทำให้มีข้อผิดพลาดมาก
OpenLibrary จะรวมไว้เป็น work เดียว และเก็บข้อมูลภาษาและผู้แปลไว้ที่ edition
ความซ้ำซ้อนที่เห็นตอนนี้น่าจะเกิดจากปัญหาในกระบวนการรวมอัตโนมัติตามภาษา
อุดมคติคือให้ผู้ใช้สำรวจต้นฉบับและฉบับแปลไปพร้อมกันได้
ขอแนะนำ LibraryThing
รู้สึกว่าดีกว่า Goodreads มาก
การแยกโครงสร้าง WEMI (work, expression, manifestation, item) ของหนังสือเป็นเรื่องสำคัญ
“ฉันอ่าน Don Quixote แล้ว” เป็นคำพูดในระดับ work แต่ “หนังสือของฉันมีคราบกาแฟ” เป็นคำพูดในระดับ item
ในการแข่งขันอ่านหนังสือระดับรัฐ มีการจัดการหนังสือด้วย ISBN อย่างเดียว ทำให้นักเรียนหาเจอยาก
จึงเพิ่ม SQL join โดยใช้ฐานข้อมูล ISBN mapping ของ WorldCat เพื่อเชื่อม ISBN อื่น ๆ ที่เป็นเนื้อหาเดียวกัน
ผลคือในช่วง 10 ปี นักเรียนได้อ่านหนังสือ เพิ่มอีกกว่าหนึ่งล้านเล่ม
Anna’s Archive มีส่วนช่วยมากในการจัดระเบียบข้อมูลที่เกี่ยวกับ ISBN
พวกเขาใช้การ สแครป WorldCat มาใช้งาน และตอนนี้ก็กำลังสร้างฐานข้อมูล ISSN (สิ่งพิมพ์ต่อเนื่อง) อยู่ด้วย
ข้อมูล ISSN ยังขาดแคลนมากเมื่อเทียบกับหนังสือ
มีคนเตือนให้จำไว้ว่า Open Library เริ่มต้นจากงานยุคแรกของ Brewster Kahle (ผู้ก่อตั้ง Internet Archive) และ Aaron Swartz
บล็อกที่เกี่ยวข้อง
เคยมีหลายครั้งที่เห็นหนังสือในร้านแล้วซื้อกลับบ้าน แต่พอกลับมาถึงพบว่า มีฉบับเดียวกันอยู่แล้ว
ถ้าค้นรายการหนังสือที่ตัวเองมีด้วย ISBN ได้ ก็น่าจะป้องกันการซื้อซ้ำแบบนี้ได้
เคยทำเว็บไซต์จัดการหนังสือเป็นโปรเจกต์ส่วนตัว โดยใช้ ISBNDB API
เวลา ค้นหาจากชื่อหนังสือ ผลลัพธ์จะยุ่งมากเพราะมีทั้งหลายฉบับ หลายภาษา และหลายรูปแบบการเข้าเล่มปนกัน
เลยใช้ Jaccard similarity มาจัดระเบียบผลลัพธ์ แต่ก็ยังไม่สมบูรณ์
ตอนนี้กำลังพิจารณา OpenLibrary เป็นทางเลือก
รู้สึกว่าแอป StoryGraph ก็ไม่เลว
ชอบอินเทอร์เฟซที่คำนึงถึง ผู้ใช้ที่ไม่อยากใช้ฟีเจอร์ AI
ฟังก์ชันค้นหาก็ดีด้วย
ส่วนตัวใช้มาตั้งแต่ปี 2017 และเลือกเพราะตั้งใจ ลดการพึ่งพาตลาดผูกขาดไม่กี่ราย
ISBN มี รหัสระบุสำนักพิมพ์ รวมอยู่ด้วย ดังนั้นหนังสือเล่มเดียวกันอาจมี ISBN ต่างกันไปตามแต่ละตลาด
เป็นบริการฟรี ดังนั้นอาจต่างกันไปในแต่ละประเทศ
เพราะฉะนั้นแม้ชื่อสำนักพิมพ์จะไม่ได้ฝังอยู่ตรง ๆ แต่ก็ยังระบุได้จากโครงสร้าง