- Anna’s Archive’ın kapsadığı 100 milyondan fazla kitap verisini tek ekranda keşfetmek için, ISBN adlı sınırlı tanımlayıcı alanını bir haritaya dönüştüren bir yaklaşım gerekiyor
- ISBN13,
978-/979-önekleri ve sondaki sağlama toplamı hariç tutulduğunda yaklaşık 2 milyar yuvalık tek boyutlu bir alan; ülke ve yayınevi aralıkları önek bazında atanıyor - Basit satır bazlı yerleşim veya Hilbert curve, ISBN yapısını görmeyi zorlaştırabildiğinden, ondalık basamakları 2D koordinatlara taşıyan Bookshelf-Curve kullanılıyor
- Harita karoları PNG ve JSON statik dosyaları olarak sunuluyor; WebGL/GLSL shader’ları yayın yılı, elde bulunma oranı, veri kümesi karşılaştırması ve yayınevi vurgulaması gibi render ve filtreleme işlemlerini anında yapıyor
- ThreeJS, React, MobX ve react-threejs-fiber tabanlı statik bir frontend olarak uygulanmış; büyük ölçekli metin render’ı ve yakınlaştırma/kaydırma performansı gerçek kullanılabilirliği belirliyor
ISBN alanını görselleştirme hedefi yapma nedeni
- Kütüphaneler uzun zamandır insanlığın bilgisini bir araya getiriyor; dijital çağda belirli ölçütleri karşılayan eserleri kapsamlı biçimde toplamak mümkün hale gelebilir
- Gölge kütüphanelerden biri olan Anna’s Archive’ın 100 milyondan fazla kitabı tek seferde keşfetmeyi sağlayacak bir görselleştirmeye ihtiyacı vardı
- Hedef veriler; başlık, yazar, ülke, yayınevi, yayın dönemi, kitabı bulunduran kütüphane sayısı ve dijital erişilebilirlik gibi bilgileri içeriyor
- Etkileşimli görselleştirme veri kümesi seçimi, tekil kitap arama, yayın yılı filtreleme ve özel shader tabanlı bileşik görselleştirmeyi destekliyor
- En yüksek yakınlaştırmada her kitabın rafta duran bir kitap gibi göründüğü bir ifadeye geçiliyor
ISBN’in yapısı
- ISBN13, yayımlanan neredeyse tüm kitaplara verilen 13 haneli bir numaradır
- Günümüzde ISBN13’ün ilk üç hanesi
978-veya979-olarak sabittir; son hane ise sağlama toplamıdır - Bu nedenle gerçek ISBN13 alanı yaklaşık 2 milyar yuva olarak görülebilir
978-ve979-önekleri, ISBN13’ün European Article Number’ın bir alt kümesi olmasından kaynaklanan bir yapıdır; bu sabit önek Bookland olarak adlandırılır- Büyük ISBN blokları International ISBN Agency tarafından uluslararası kuruluşlara atanır; her ülke de kendi bloğunu yayınevleri bazında yeniden böler
- ISBN blokları her zaman önek (prefix) bazında atanır
978-4Japonya’ya atanmıştır- Japonya
978-4-312önekini bir yayınevine atar - Bu yayınevi
000000-99999aralığındaki öğeleri atayarak978-4-312-99999-Xgibi ISBN’ler oluşturabilir
- Ülke öneki ne kadar uzunsa, içinde atanabilecek kitap sayısı o kadar azalır
- Japonya 100 milyon ISBN’lik bir alana sahiptir
- Singapur
978-9971-önekiyle başlar ve yalnızca 100 bin ISBN mümkündür
Tek boyutlu ISBN’i iki boyuta açma yöntemi
978-/979-önekleri ve sağlama toplamı kaldırıldığında ISBN, 0 ile 2 milyar arasında ondalık tek boyutlu bir değer haline gelir- En basit yöntem pikselleri yukarıdan başlayarak satır satır doldurmaktır; ancak küçük bölgeler yatayda uzayıp ISBN yapısını görmeyi zorlaştırır
- Hilbert curve küçük bölgeleri kareye daha yakın hale getirir, ancak veride olmayan mekânsal yapı artefaktları oluşturabilir
- Bu görselleştirme, veride olmayan yapılardan kaçınmak için ISBN’in ondalık niteliğinden yararlanan Bookshelf-Curve kullanır
Bookshelf-Curve
- Bookshelf-Curve, ilk ondalık basamaktaki
0-9değerlerini yan yana, sonraki basamaktaki0-9değerlerini ise yukarı-aşağı yerleştirme yöntemini özyinelemeli olarak tekrarlar - İki katmandaki dikdörtgen oranlarını korumak için her bloğun en-boy oranı
√10, yani yaklaşık 3,16:1 olur - Bu yapı A4 kâğıdın özyinelemeli en-boy oranı kavramına benzer; ancak ikiye bölmek yerine 10 aralığa böler
- Koordinat dönüşümü, ISBN’in basamaklarını birer atlayarak koordinat olarak kullanmaya dayandığı için basittir
- Uygulama kodu genelleştirme denemesi nedeniyle 50 satır oldu; ancak ilke, belirli bir ISBN konumunu elle izleyerek bulabilecek kadar anlaşılırdır
Harita karoları ve veri kodlama
- Her ISBN öneki için karo görüntüsü oluşturulur
- Hedef karo boyutu yaklaşık
100kBidi; bunun sonucunda karo boyutu2000 × 633piksel oldu - Her veri kümesinde piksele kaydedilen bilgi farklıdır
- Yayın yılı veri kümesi,
1800çıkarılmış değeri 8 bit aralığında saklar - Kırmızı kanal, o piksel içindeki kitapların ortalama yayın yılını içerir
- Mavi kanal, var olan kitap oranını içerir
- Örneğin kitapların %50’si mevcutsa mavi kanal değeri
127/255olur
- Yayın yılı veri kümesi,
- En yüksek yakınlaştırma seviyesinde doğruluk için 1 kitap 1 piksele eşlenir
GLSL shader tabanlı render
- Başlangıçta RGB verileri doğrudan karolarda saklanıyordu; ancak esnekliği artırmak için daha soyut veriler saklanıp asıl render işlemi GPU’daki GLSL fragment shader içinde yapıldı
- Bu yöntem, renk paletini sonradan seçmeyi, rastgele dönüşümleri ve filtreleri anında uygulamayı veya birden çok veri kümesini o anda birleştirmeyi mümkün kılar
- Yayın yılı verisi
1800-2055aralığını saklar; ancak verinin %95’i1985-2024aralığında olduğundan shader’da bu aralığa daraltılarak ifade edilebilir heatmapColor(float)fonksiyonu0-1değerini kullanıcının seçtiği renk ölçeğine dönüştürür$dataset_xsöz dizimi GLSL’in kendi söz dizimi değil, yalnızca shader’ın gerçekten okuyacağı görüntüleri yüklemek için kullanılan basit regex tabanlı bir şablon söz dizimidir- Görselleştirmenin ⚙️ Advanced seçeneğinde shader doğrudan düzenlenebilir ve değişikliklerin sonucu gerçek zamanlı yansıtılır
- Her veri kümesi pikselinin anlamı README içinde özetlenmiştir
Yakınlaştırıldığında kitaplık gibi görünmesini sağlayan ifade
- Tam yakınlaştırılmış görünümde her piksele kitap gibi görünen bir stil uygulanır
- Her kitap rastgele genişliğe, yüksekliğe ve desene sahip olacak şekilde işlenir
- Gerçek kitap şekliyle tamamen aynı değildir; ancak maksimum yakınlaştırmadaki ekranı daha canlı bir sahne gibi gösterir
- Bu stilin tamamı shader içinde uygulanır
- GLSL ve JavaScript’te aynı rastgele sayı üretme sonucuna ihtiyaç duyulduğu için, kitap yüksekliğini hesaplayıp metin sınırlarını hizalama kısmı zordu
- Mevcut yakınlaştırma değeri uniform olarak geçirilip iki yakınlaştırma seviyesi arasında fade-in yapılırsa kitaplık stili yumuşak biçimde gösterilebilir
Metin, ağaç yapısı ve performans
- Görüntü karolarında olduğu gibi metin de yakınlaştırma seviyesi ve view frustum culling’e göre hiyerarşik yapı olarak render edilir
- Uygulamada react-threejs-fiber kullanılır
- React, görünüm hareket ettikçe sahne öğelerini özyinelemeli olarak ekler; her önek için Plane, HTML metin ve alt önek düğümleri oluşturur
- Çok sayıda metni render ederken başlangıçta büyük performans sorunları yaşandı
- HTML’i SVG’deki
<foreignObject />içine koyup bunu canvas’adrawImageile render ettikten sonra texture olarak yükleme yöntemi en iyi yaklaşım oldu - Bu yöntem çalıştı; ancak render sürecinde eşzamanlı olarak her seferinde 20ms gecikme yarattı
- SVG WebWorker içinde çizilemediği için WebWorker’a taşımak zordu
- Asıl performans sorunları; HTML öğe sayısını azaltarak, kare başına eklenen DOM içeriğini sınırlayarak ve özellikle
text-shadowCSS filtre yığınını kaldırarak büyük ölçüde iyileştirildi
Barkod ve yayınevi aralıkları
- Maksimum yakınlaştırmada her kitapta barkod gösterilir
- Barkod, kitapların ISBN sırasına göre dizildiği kavramını güçlendirmek için eklendi
- Barkod render kütüphanesi yerine, 13 haneli sayıyı barkod olarak render eden ve check digit’i de hesaplayan Libre Barcode TTF fontu kullanılır
- İşletim sisteminin metin render optimizasyonları sayesinde bu yöntem pratik ve performanslıydı
- Her grup genellikle ülke bazında büyük bir aralığa, yayınevleri ise onun içinde daha küçük aralıklara sahiptir
- Grup ve yayınevlerine ayrı ayrı benzersiz rastgele renkler atanır
- Bir yayınevinin birden fazla aralığı olsa da aynı renk kullanılır
- Tüm aralıkları aynı anda vurgulamak için her yayınevine benzersiz ID verilir ve bu RGB bileşeni olarak saklanır
- Yayınevi renklerinde hâlâ tatmin edici olmayan noktalar var
- Yayınevi renkleri heatmap renk ölçeğiyle çakışır
- Ülke aralıklarını görmek zordur
Arama geçişi ve uçuş yolu
- Bir kitap arandığında veya mini haritaya tıklandığında ilgili konuma uçuş geçişi yapılır
- İyi görünen bir uçuş yolu hesaplamak beklenenden daha zordu
- Parabol uydurma ile sonuç sıradandı; sonrasında ayrı bir dönüşüm alanı kullanan bir yaklaşım denendi
- Nihai sonuç mükemmel değil ve yaklaşık 500 satır kodla biraz fazla tasarlanmış hissi veriyor; ancak ilk yaklaşımdan daha iyi çalışıyor
Mimari ve işleme hattı
- Backend gerekmez
- Görüntü karoları PNG olarak saklanır
- Veri ağacı JSON olarak saklanır
- HTML, JS, CSS, PNG ve JSON’u GitHub Pages gibi statik dosya barındırma hizmetlerine yüklemek yeterlidir
- Frontend ThreeJS, React ve MobX kullanır
- Bu kombinasyon, yeniden kullanılabilir bileşenlerle reaktif, deklaratif ve GPU hızlandırmalı 2D/3D sahneler oluşturmak için kullanışlıydı
- İşleme betikleri çoğunlukla JS ile yazıldı ve doğrudan JSON ile PNG çıktısı üretir
- Bazı betiklerin 250GB kaynak dosyaları okuyup SQLite’a çıktı vermesi gerektiğinden Rust ile yazıldı
Sonuç ve kod
- Ortaya çıkan sonuç, ISBN verilmiş yayımlanmış kitapları esnek biçimde görselleştiren bir yöntem oldu
- Bu proje, ISBN’in tanımlayıcı alanının ancak yeterli olacak kadar küçük tasarlanmış olması sayesinde mümkün oldu
- Aynı çalışma UUID ile yapılsaydı, alanın büyük kısmı devasa bir boşluk olurdu
- Kaynak kodu isbn-visualization üzerinde yayımlanmıştır
1 yorum
Hacker News görüşleri
Amazon’u kurarken tam olarak böyle bir şey yapmak istemiştim, ancak ISBN yerine Library of Congress üçlü sınıflandırmasını kullanmayı planlıyordum
Sonunda veri sağlayıcıları Baker & Taylor ve Books In Print, üçlü sınıflandırmayı tek bir metin dizisine ezip geçince sınırları güvenilir biçimde bulmak mümkün olmadı ve doğru dürüst başlayamadan vazgeçmek zorunda kaldım
1994~1995 dönemi web’inde böyle bir “uçuş” tarzı gezinmeyi hayata geçirmek de kesinlikle kolay olmazdı; harika bir çalışma
LoC Classification ve LoC Subject Headings’e epey baktım, ama ikisi de serbestçe erişilebilen, gerçekten kullanışlı makinece okunabilir biçimlerde sunulmuyor; bu üzücü. PDF’lerle bir yere kadar çeşitli hileler yapılabiliyor
Özellikle Classification’ın eyalet hukuku bölümü, eyaletler arasında sınıflandırma yoğunluğu açısından çok dengesizdi; hatırladığım kadarıyla NY ve CA ezici biçimde karmaşıktı, PA biraz geriden üçüncü sıradaydı, birçok “flyover” eyalet ise neredeyse komik derecede basit ve birbirine benziyordu. Bu da her eyaletin kanun, düzenleme ve içtihat hukukunun karmaşıklığını yansıtıyor gibi görünüyor
Bir diğer ilginç tarihsel bilgi de şu: sınıflandırma sistemi ve alfabetik üst düzey ayrımın, LoC’nin kökenini oluşturan Thomas Jefferson’ın kişisel kütüphanesinden doğrudan geldiği anlaşılıyor
İlgileniyorsanız, Hathi Trust’taki Librarian of Congress’in Kongre’ye sunduğu yıllık raporlarda Classification’ın gelişim ve genişleme tarihine dair çok şey görülebilir
Classification: <https://www.loc.gov/catdir/cpso/lcco/>
Subject headings: <https://id.loc.gov/authorities/subjects.html>
Annual reports — Recent: <https://www.loc.gov/about/reports-and-budgets/annual-reports...> / Historical archive to ~1866: <https://catalog.hathitrust.org/Record/000072049>
İş yaptığım şirketler arasında teknik açıdan en geri kalmış olanlardan biriydi; 2020 başında hesabı kapatana kadar bile satın alma siparişlerini ve mutabakatı kâğıt, PDF ve e-postayla yürütüyordu. Hatta bir ara belgeleri faksla göndermemi istedikleri bile olmuştu sanırım
ISBN’ler bazen farklı kitaplara mükerrer atanabildiği için [0], “ISBN uzayındaki tüm kitaplar” ifadesi abartılı olabilir
Ayrıca kontrol hanesi ISBN’nin geri kalanıyla uyuşmayan hatalı ISBN taşıyan kitaplar da var. Kontrol hanesi düzeltilince başka bir kitapla çakışıyorsa, bu durumda blog yazısının varsaydığı ISBN uzayının dışında kalıyor olur
[0] https://scis.edublogs.org/2017/09/28/the-dreaded-case-of-dup...
Çek yayınevlerinin bilinen en düşük ISBN’lerine bakarken farklı bir renk gözüme çarptı; https://books.google.cz/books?vid=ISBN9788000000015&redir_es... geçerli bir ISBN gibi görünmüyor :-) ama bu kitabın gerçekten böyle bariz sahte bir ISBN taşıyıp taşımadığını mı, yoksa bunun Google Books verisindeki bir hata mı olduğunu bilmiyorum
Etkileyici bir sunum
Ancak bu ekran tüm ISBN kataloğunu değil, yalnızca Anna's Archive arşivinde bulunanları yansıtıyor. Anna’nın toplama yanlılığı nedeniyle belirli dil aralıklarına doğru bir kayma görülüyor ve siyah renkle gösterilen bölgeler arşivde olmayan öğeleri ifade ediyor
Metadata veritabanı çeşitli kaynaklardan geliyor ve bildiğim kadarıyla oldukça kapsamlı. Siyah alanlar büyük olasılıkla çoğunlukla atanmış kitabı olmayan bölgeler
Gerçekten harika; şaşırtıcı bir tutku projesi ve mükemmel bir kaynak
Yakınlaştırınca başlık ve barkod görünüyor, üzerine gelince kapak ve ayrıntılar da çıkıyor. İstenebilecek neredeyse her şey var
İyileştirme fikri olarak, sol üstteki yüzen beyaz paneli ve sağ üstteki öğeleri gizlemek için onay kutuları olsa iyi olurdu. Bu tür görselleştirmelere dalmayı seviyorum, ama yüzen öğeler o deneyimden biraz koparıyor ve eğlenceyi de işlevselliği de biraz azaltıyor
Bu, Microsoft’un sonlandırmadan önce nörogörüntüleme alanında kullanılan mükemmel web arayüzü Microsoft Silverlight PivotViewer için biçilmiş kaftan bir örnek
Gary W. Flake’in kullanımını gösterdiği etkileyici bir TED konuşması var
https://m.youtube.com/watch?v=LT_x9s67yWA
Ayrıca 2011’de yazılmış bir IEEE makalesi de var. Bunun bir web standardı olmaması gerçekten üzücü
https://www.dropbox.com/scl/fi/bl8zkjs3y47q3377hh3ya/Yan_Wil...
Çok hoş bir görselleştirme
Burada daha da hoş başka gönderiler var: https://software.annas-archive.li/AnnaArchivist/annas-archiv...
Benim çalışmam da https://isbnviz.pages.dev adresinde
Yakınlaştırınca kitaplık gibi görünüyor. Gerçekten harika
Muhteşem. Gerçek dünyadaki Library of Babel gibi: https://libraryofbabel.info/
Bunca VR saçmalığının arasında, gerçek bir sonsuz kütüphane ya da sonsuz müze için para ödeyebilirmişim gibi geliyor
Yasal olarak sunulan, indirilebilir tüm metinlere erişim sağlayan bir proje olsaydı çok daha ilginç olurdu. Mesela şuradaki arayüz gibi:
https://onlinebooks.library.upenn.edu/
Mevcut sunum biçimi biraz bunaltıcı geldi
Sol üstteki preset bölümünün aslında AA dahil mi, nadirlik, Google Books dahil mi gibi ek veri görselleştirme eksenlerine açıldığını anlamam biraz zaman aldı. Yine de görselleştirme ve veri derinliği zengin
Bölgesel kümelenme görünümünü gösteren https://archive.anarchy.cool/blog/all-isbns.html#visualizing da güzeldi
Yıl preset'i de kendi başına, bölgelere göre yayıncılık faaliyetini görmek açısından ilginçti. Poland son dönemde çok hareketli, Norway ise nispeten sakin görünüyor. China'nın 2005 civarında artmaya başladığı ve son 10 yılda muazzam büyüdüğü anlaşılıyor
United States'te de gariplikler var. Daha önce duymamıştım ama Blackstone Audio, Blurb Inc., Draft2Digital olağanüstü sayıda ISBN yayımlamış
Biraz daha minimalist bir görünüm (daha az renk, aynı anda yalnızca bir metin seviyesi gösterme) burada:
https://phiresky.github.io/isbn-visualization/?dataset=all&g...
N publishers gibi bazı metinleri gizleyerek ya da mouseover bilgisini azaltarak daha da ayarlanabilir gibi görünüyor
Uçuş yolu, hiperbolik üst yarı düzlem üzerindeki hareket olarak modellenirse oldukça makul düşünülebilir. x, uç noktalar arasındaki doğrusal yol üzerindeki konum; y ise viewport'un bir kenar uzunluğu olarak alınabilir
Birbirine denk gelen iki ölçü düşündüm. İlki, hiyerarşik döşeme haritasını varsayıp yüklenen tile sayısını en aza indiren yöntem. y'yi viewport'un bir kenar uzunluğu olarak alırsak, x kadar yatay hareketin maliyeti x/y tile olur; y_0'dan y_1'e yakınlaştırma/uzaklaştırma yapılırsa abs(log_2(y_1/y_0)) tile yüklenir, bu da ds = dy/y ile örtüşür. Birleştirince ds^2 = (dx^2 + dy^2)/y^2 elde edilir ve bu tam olarak üst yarı düzlem metriğidir
Diğer bir bakışla, viewport'un “optik akışını” bir anlamda minimize etmek olarak görülebilir. Bu da yalnızca ölçek farkıyla aynı metriği verir. Yakınlaştırma olmadan x kadar pan yapılırsa her şey x/y kadar, yani viewport'a göre oran kadar hareket eder. k kat yakınlaştırılırsa (u,v) pikseli (ku,kv)'ye gider ve yer değiştirme (u,v)(k-1) olur. Bir kenar uzunluğu y'den y+dy'ye giderse bu, (u,v)dy/y olur; dolayısıyla yer değiştirmeyi nasıl ortaladığınıza bağlı olarak dy/y'nin bir sabit katı çıkar
O zaman istenen geodezikler, merkezi y=0 üzerinde olan horocycle yaylarıdır; ama eğri boyunca hareketi hesaplamak biraz iş ister. θ_0'dan θ_1'e bir yay alırsanız toplam süre, dtheta/y = dθ/sin(θ) integralinden çıkar; yani tam yapmak için t = ln(csc(θ)-cot(θ)) ifadesini ters çevirmek gerekir. Yaklaşık hesaplamanın daha iyi olacağını düşünmüştüm ama Mathematica bunun θ = atan2(1-2e^(2t), 2e^t) olduğunu söyledi, yani o kadar da kötü değil
“blub space” mantığıyla karşılaştırınca, oradaki etkin metrik sanırım ds^2 = dz^2 + (z+1)^2 dx^2. z=1/y büyütme seviyesi olan kutupsal koordinat ve dz=dy/y^2 kullanılırsa ds^2 = dy^2/y^4 + dx^2*(1/y^2 + ...) elde edilir. Yani mevcut uygulama, hiperbolik modele kıyasla yüksek büyütme seviyelerinde pan işlemine çok daha fazla zaman harcıyor gibi görünüyor. 4 kattan 2 kata inmenin maliyeti, 2 kattan 1 kata inmenin iki katı; oysa görsel olarak aynı
Onların zoom'u bir ölçek çarpanı değil, benim “y” dediğime karşılık geliyor; dolayısıyla metrik ds^2 = dy^2 + (C-y)^2 dx^2 oluyor. Burada C, maksimum büyütme seviyesinden biraz daha büyük. Ayrıca eğri daha uzağa uzaklaştırmaya çalıştığında devreye giren özel bir işlem de var
Tamamen uzaklaştırılmış durumda (zoom=1) bir uçtan ötekine pan yapmanın maliyetini eşitleyecek şekilde normalize edilirse, çok derin yakınlaştırılmış durumda pan maliyeti neredeyse düzleşiyor; nispeten daha az yakınlaştırılmış durumlarda ise hiperbolik modele göre daha yüksek kalıyor. Bu da kısa mesafelerde viewport'un çok hızlı hareket ediyormuş gibi hissedilmesine, uzun mesafelerde ise neredeyse sonuna kadar uzaklaştırıyormuş gibi görünmesine katkıda bulunuyor. Orta büyütme seviyeleri dezavantajlı olduğundan, neredeyse tamamen oraya gitmek daha iyi hale geliyor