- Letterboxd जैसा साफ़-सुथरा और व्यावहारिक book logging app बनाने की कोशिश में, ISBN सिस्टम की संरचनात्मक समस्या सबसे बड़ा अवरोध निकली
- किताब खोज सुविधा के लिए Google Books API इस्तेमाल करते समय पता चला कि वही रचना कई ISBN versions में अलग-अलग items के रूप में लौटती है
- इसकी वजह bibliographic structure (FRBR model) में ‘work’, ‘expression’ और ‘manifestation’ का अलग-अलग होना है; यानी उपयोगकर्ता सिर्फ़ ‘मैंने यह किताब पढ़ी’ दर्ज करना चाहे, तब भी डेटा बहुत बारीक हिस्सों में बँटा होता है
- OpenLibrary ‘work’-केंद्रित data structure देता है, लेकिन उसमें भी duplication और incompleteness बनी रहती है, इसलिए वह पूरी तरह उपयुक्त विकल्प नहीं बन पाता
- फ़िल्म database TMDB जैसी high-quality public metadata infrastructure किताबों की दुनिया में नहीं है, और यही book-centric social platform development की एक बड़ी बाधा है
Letterboxd और book platforms की तुलना
- Letterboxd अपने clean interface और non-intrusive social features की वजह से फ़िल्म देखने के रिकॉर्ड को आसानी से मैनेज करने देता है
- उपयोगकर्ता कौन-सी फ़िल्म देखी और कब देखी, इसे आसानी से दर्ज कर सकते हैं
- इसके विपरीत GoodReads का जटिल UI और multi-step click structure किताबों का रिकॉर्ड रखना असुविधाजनक बनाता है
- ‘पढ़ी गई किताबें’ और ‘पढ़नी हैं’ एक ही स्क्रीन पर मिली होती हैं, और reading challenges, newsletters जैसे अतिरिक्त elements जगह घेरते हैं
- GoodReads के असुविधाजनक होने की एक वजह यह भी है कि वह Amazon के book-selling business की कम प्राथमिकता वाला derivative product है
- Storygraph में भी मिलती-जुलती समस्याएँ हैं, इसलिए उपयोगकर्ता अंततः Obsidian files में अपने निजी रिकॉर्ड मैनेज करने लगते हैं
Google Books API और ISBN की समस्या
- किताब खोज सुविधा बनाने के लिए Google Books API का उपयोग किया गया, लेकिन वही रचना कई ISBN के साथ duplicate results में दिखाई दी
- उदाहरण के लिए “The Last Unicorn” खोजने पर hardcover, paperback, eBook, revised editions आदि अलग-अलग ISBN के साथ लौटते हैं
- हर ISBN एक अलग format या edition को दर्शाता है, लेकिन उपयोगकर्ता तो बस इतना दर्ज करना चाहता है कि ‘उसने यह किताब पढ़ी’
- यह संरचना search और data integration को कठिन बनाती है, इसलिए single-work unit पर आधारित रिकॉर्ड सिस्टम बनाने के लिए उपयुक्त नहीं है
FRBR model और ‘work’ इकाई वाला दृष्टिकोण
- library science में इस्तेमाल होने वाला FRBR model book data को चार स्तरों में बाँटता है
- Work (कृति): स्वयं अमूर्त रचना (उदाहरण: उपन्यास "The Last Unicorn")
- Expression (अभिव्यक्ति): किसी रचना का विशिष्ट संस्करण
- Manifestation (रूप): उस संस्करण का भौतिक format (paperback, hardcover आदि)
- Item (वस्तु): किसी collection में मौजूद व्यक्तिगत भौतिक प्रति
- Google Books मुख्यतः ‘expression’ या ‘manifestation’ स्तर का डेटा लौटाता है, जबकि उपयोगकर्ता को ‘work’ स्तर की अमूर्त इकाई चाहिए
- OpenLibrary ‘work’-केंद्रित data structure देता है, लेकिन उसमें अब भी duplicate entries मौजूद हैं
- उदाहरण: Yoko Ogawa की Hotel Iris खोजने पर वही कृति चार बार duplicate दिखती है
data quality और ecosystem की सीमाएँ
- Letterboxd की बुनियाद The Movie Database (TMDB) पर है, और TMDB के पास लगभग 10 लाख फ़िल्मों का डेटा है
- दूसरी ओर OpenLibrary में 4 करोड़ से अधिक works शामिल हैं, लेकिन उनमें अधूरा और बिना refinement वाला data बहुत है
- फ़िल्म data में commercial platforms और community contributions का संयोजन होने से quality बेहतर है, जबकि book data का scale बहुत बड़ा है और funding कम है
- इसी कारण किताबों के लिए Letterboxd जैसी सेवा बनाने हेतु ज़रूरी foundational data मौजूद नहीं है
निष्कर्ष और आगे की कोशिश
- पूरी तरह open source book metadata infrastructure मौजूद न होने के कारण, book logging platform बनाना फ़िल्मों की तुलना में कहीं अधिक कठिन काम है
- लेखक अब भी स्वतंत्र book logging system बनाने की कोशिश जारी रखने वाला है
- फ़िल्मों में अपनी पसंद खोजने के अनुभव की तरह किताबों के रिकॉर्ड में भी personalized approach की ज़रूरत है
4 टिप्पणियां
हाँ... ISBN तो प्रकाशन की पहचान के लिए होता है, कंटेंट की पहचान के लिए नहीं...
टाइटल बहुत ज़्यादा clickbait है lol
लगता है कि कंटेंट के identifier वाली जगह खाली है :(
यह भी सच है कि ISBN सिस्टम में व्यवस्थित वर्गीकरण पर बहुत ज़्यादा विचार नहीं किया गया है...
नियमों के मुताबिक हर पुनर्मुद्रण को अलग नंबर दिया जाना चाहिए, लेकिन सबसे निचली श्रेणी प्रकाशक होने की वजह से, कृतियों के हिसाब से वर्गीकरण की ज़रूरत होने के बावजूद उसका प्रबंधन आसान नहीं है।
Hacker News की राय
इससे MusicBrainz के डेटाबेस स्ट्रक्चर की याद आती है
उदाहरण के लिए Nirvana का Nevermind एल्बम एक release group है, लेकिन टेप, CD, LP, प्रमोशनल रिलीज़ और अलग-अलग देशों के री-रिलीज़ जैसे कई वर्ज़न मौजूद हैं
कुछ मामलों में कैटलॉग नंबर या बारकोड अलग होने से फर्क पता चलता है, लेकिन कभी-कभी एक ही कोड होने पर भी वे वास्तव में अलग वर्ज़न होते हैं
एक ही रिकॉर्डिंग भी remastering, एडिटिंग या censorship की वजह से अलग हो सकती है
MusicBrainz इन फर्कों को बहुत बारीकी से ट्रैक करता है और साफ़ तौर पर बताता है कि कौन-सी रिकॉर्डिंग वही है और कौन-सी नहीं
कवर सॉन्ग या standard compositions जैसे मामलों में, जहाँ कई artists ने रिकॉर्ड किया हो, वह ‘work’ स्तर पर composer और lyricist की जानकारी जोड़ता है
ऐसा सटीक relational database design रचनाओं की समानता और अंतर को दर्ज करने में बहुत उपयोगी लगता है
संबंधित लिंक
bookbrainz.org/about
अगर इसका schema MusicBrainz जैसा है, तो डेटा extraction बहुत आसान होने की उम्मीद है
मैंने अकाउंट बनाकर डेटा खुद अपलोड किया और कई बार सुधारने के बाद उसे सफलतापूर्वक दर्ज कर पाया
संदर्भ के लिए मुझे एक Chinese वेबसाइट पर उसी Australian edition की CD की जानकारी मिली, और तब समझ आया कि बाज़ार के हिसाब से बहुत हल्के-फुल्के अलग वर्ज़न मौजूद होते हैं
इस बात पर कि लोग ‘unique identifiers’ को अपडेट करने में बहुत ढीले होते हैं, MusicBrainz टीम से गहरी सहानुभूति होती है
1987 संस्करण और 1989 संस्करण (‘Peace Train’ हटाया गया संस्करण) का UPC नंबर एक ही था
90 के दशक के बीच में सेकंड-हैंड CD स्टोर्स में हटाने से पहले वाला संस्करण ढूँढ़ने के लिए काफी मेहनत करनी पड़ी थी
बाकी में भ्रम इसलिए हुआ क्योंकि अलग-अलग क्षेत्रों के कई वर्ज़न थे जिनमें track count अलग था
अगर track-wise artist जानकारी देने की सुविधा होती, तो शायद search accuracy और बेहतर होती
सिर्फ़ टाइपो सुधार जैसा अंतर हो तब भी उन्हें अलग-अलग पहचानना मुश्किल होता है
Wikidata एक FRBR-compatible open database है, और पिछले कुछ वर्षों में किताबों से जुड़ी इसकी गुणवत्ता काफी बेहतर हुई है
उदाहरण में दी गई Ogawa Yoko की Hotel Iris एक ही रचना नहीं, बल्कि एक-दूसरे से अलग अनुवाद हैं
अनुवाद को मूल कृति से अलग एक derivative work माना जाना चाहिए
लेकिन सूचियाँ आपस में गड़बड़ मिली हुई हैं, इसलिए त्रुटियाँ बहुत हैं
OpenLibrary में उन्हें एक ही work के तहत रखा जाता है, और भाषा व translator की जानकारी edition में सेव की जाती है
मौजूदा duplication शायद भाषा-आधारित automatic merge प्रक्रिया से पैदा हुई समस्या लगती है
आदर्श यही है कि उपयोगकर्ता मूल और अनुवाद, दोनों को साथ में explore कर सकें
LibraryThing की सिफारिश की गई
यह Goodreads से कहीं बेहतर लगता है
किताबों की WEMI structure (work, expression, manifestation, item) को अलग पहचानना महत्वपूर्ण है
“मैंने Don Quixote पढ़ी” work स्तर की बात है, जबकि “मेरी किताब पर कॉफ़ी के दाग हैं” item स्तर की बात है
राज्य-स्तरीय reading competition में किताबों को सिर्फ़ ISBN से मैनेज किया जाता था, इसलिए छात्रों को उन्हें ढूँढ़ना मुश्किल होता था
इसलिए WorldCat के ISBN mapping database का उपयोग करके वही सामग्री रखने वाले अलग ISBNs को जोड़ने के लिए SQL join जोड़ा गया
उसके बाद 10 साल में छात्रों ने अतिरिक्त दस लाख से ज़्यादा किताबें पढ़ीं
Anna’s Archive ने ISBN से जुड़े डेटा को व्यवस्थित करने में बड़ा योगदान दिया है
उसने WorldCat को scrape करके इस्तेमाल किया, और अब ISSN (periodicals) डेटाबेस भी बना रहा है
किताबों की तुलना में ISSN की स्थिति अभी बहुत कमजोर है
यह याद दिलाया गया कि Open Library की शुरुआत Brewster Kahle (Internet Archive के संस्थापक) और Aaron Swartz के शुरुआती काम से हुई थी
संबंधित ब्लॉग
कई बार ऐसा हुआ कि किसी असली बुकस्टोर में किताब देखकर खरीदी, लेकिन घर आकर पता चला कि वही edition पहले से मौजूद है
अगर मैं ISBN के आधार पर अपनी collection list खोज पाता, तो ऐसी duplicate purchase से बच सकता था
एक personal project में ISBNDB API का उपयोग करके book management साइट बनाने का अनुभव साझा किया गया
title search करने पर ढेर सारे editions, भाषाएँ और binding formats एक साथ मिल जाते थे, जिससे परिणाम बहुत जटिल हो जाते थे
Jaccard similarity के आधार पर परिणामों को व्यवस्थित किया गया, लेकिन वह पूरी तरह सही नहीं था
OpenLibrary को एक विकल्प के रूप में देखा जा रहा है
StoryGraph ऐप बुरा नहीं लगता
AI features से बचना चाहने वाले users के लिए इसका इंटरफ़ेस अच्छा है
search function भी बढ़िया है
व्यक्तिगत रूप से मैं इसे 2017 से इस्तेमाल कर रहा हूँ, और इसे de-oligopolization के मकसद से चुना था
ISBN में publisher identifier शामिल होता है, इसलिए एक ही किताब के अलग-अलग बाज़ारों में अलग ISBN हो सकते हैं
यह एक free service है, इसलिए देश के हिसाब से चीज़ें अलग हो सकती हैं
इसलिए publisher का नाम सीधे उसमें नहीं होता, लेकिन उसकी संरचना से पहचान संभव होती है