Kişisel Bilgi Mimarisi [[ve PARA]]

Bilgi mimarisi neyi çözer?

Bir vault büyüdükçe asıl maliyet depolama değil karar vermedir: “Bunu nereye koyacağım?”, “Bu bilgi hangi dosyada gerçek?”, “Bunu proje mi resource mu yapmalıyım?”, “Bu klasör daha da bölünmeli mi?” gibi küçük kararlar tekrarlanır. Sağlam mimari bu kararları azaltır.

İyi mimari üç soruya net cevap verir:

1. Bu kayıt kime ait?
2. Bu kayıt nasıl geri bulunacak?
3. Bu kayıt ne zaman gözden geçirilecek veya pasifleşecek?

Klasör, link, metadata ve [[MOC]] aynı problemi çözmez. Klasör sahiplik ve fiziksel yerleşim için; wikilink anlam ilişkisi için; metadata filtre ve sorgu için; MOC ise insan tarafından tasarlanmış gezinme için kullanılmalıdır.

PARA'yı klasör ezberi olarak kullanma

PARA'nın mantığı dört isim değil dört farklı yaşam durumudur:

• [[ 07 - Proje ve Area Operasyon Yüzeyleri|Projects ]]: Belirli bir sonuç üretmek üzere aktif çalışma.
• Areas: Bitiş çizgisi olmayan, standardı korunması gereken sorumluluk.
• Resources: Tekrar kullanılma ihtimali olan bilgi ve referans.
• Archive: Şu anda aktif olmayan ama saklanması anlamlı içerik.

Bir notun sınıfı konusu yüzünden değil, kullanım rolü yüzünden belirlenir. “SEO” hem aktif bir müşteri projesinin içinde Project olabilir, hem iş sorumluluğu olarak Area içinde görünebilir, hem de genel bilgi olarak Resource olabilir. Konuyu klasöre gömmek yerine sahipliği klasörle, çoklu bağlamı linklerle ifade etmek daha az sürtünme yaratır.

Sığ klasör, güçlü bağlam

Klasör ağacı tek hiyerarşi sunar. Bilgi ise aynı anda birden fazla bağlama ait olabilir. Bu nedenle klasör derinliğini artırmak çoğu zaman bulunabilirliği artırmak yerine karar maliyetini büyütür.

Pratik kural:

• Kök seviyesinde az sayıda işlevsel sınıf kullan.
• Alt klasörü yalnız farklı bir sahiplik veya bakım kuralı varsa aç.
• Konu çeşitliliğini klasörle değil MOC ve wikilinkle taşı.
• Biten içeriği yeni alt klasörlerle değil Archive yaşam döngüsüyle pasifleştir.

Mimari sözleşme

Vault büyürken aşağıdaki sözleşme sabit kalmalıdır:

Project: Sonuç, current state, next action ve kritik kararlar görünür olmalı.

Area: Sorumluluk tanımı, korunacak standartlar, göstergeler, rutinler ve aktif projeler görünür olmalı.

Resource: Yeniden kullanılabilir bilgi olmalı; sırf ilginç olduğu için sonsuz saklama alanına dönüşmemeli.

Archive: “Artık aktif değil” anlamına gelmeli; “çöp” anlamına değil.

Bu ayrım, [[Proje ve Area Operasyon Yüzeyleri]] ile [[Bilgi Sağlığı, Borcu ve Arşivleme]] notlarının temelini oluşturur.

Yerleştirme kararı için kısa algoritma

Yeni bir kayıt geldiğinde sırayla sor:

1. Belli bir sonucu üretmek için mi kullanılıyor? → Project
2. Sürekli korunması gereken bir sorumluluğa mı ait? → Area
3. Tekrar başvurulacak bir referans mı? → Resource
4. Şu anda aktif değil mi? → Archive
5. Henüz karar veremiyor musun? → Geçici olarak [[ 04 - Yakalama ve Inbox Kuyruğu|Inbox ]]; sonsuza kadar değil.

Bu algoritmanın amacı her kaydı mükemmel sınıflandırmak değil, belirsizliği sınırlı bir yerde tutmaktır.

Başarısız mimarinin belirtileri

• Aynı konu için çok sayıda paralel klasör.
• Bir notu kaydetmeden önce uzun süre “nereye koyacağım?” düşünmek.
• Aktif ile pasif içeriğin aynı görünürlüğe sahip olması.
• Bir proje bittiğinde dosyaların nereye gideceğinin belirsiz olması.
• Klasör adlarının anlam taşımak için sürekli derinleşmesi.
• Bir notun tek bir klasöre ait olduğu için başka bağlamlarda görünmez hale gelmesi.

Mimari bu sinyalleri azaltmıyorsa daha fazla kategori eklemek çözüm değildir.

Bilgi ağı

• [[Dosya Adı ve Tek Kaynak Doğrusu]] — mimarinin kanonik gerçek katmanı.
• [[Yakalama ve Inbox Kuyruğu]] — henüz sınıflandırılmamış girişlerin geçici sahibi.
• [[MOC, Wikilink ve Etiket Tasarımı]] — klasör dışında çoklu bağlam kurma.
• [[YAML ve Makinece Okunabilir Vault]] — mimariyi sorgulanabilir hale getirme.
• [[Bilgi Sağlığı, Borcu ve Arşivleme]] — yaşam döngüsünün bakım tarafı.